On Thu, Apr 8, 2010 at 1:57 AM, John Palmieri <jo...@redhat.com> wrote:
> > ----- "Shaneeb Kamran" <shaneebs...@gmail.com> wrote: > > > On Tue, Apr 6, 2010 at 9:24 PM, Johannes Schmid < j...@jsschmid.de > > > wrote: > > > > > > Hi! > > > > > > > > > I am not entirely sure but my guess is adding support for another > > > language would require modifications to all the applications > > > individually that want its support to be included. As far as I have > > > read (I apologize if I am wrong) GObject-introspection just makes > > > language bindings pretty straightforward but to be able to use a > > > language for scripting requires more than bindings; there are other > > > issues involved for example, mechanism for invoking the script, > > > passing objects, data conversion from the scripting language to the > > > language of the application (usually C\C++), etc. > > > > That's not true. By adding gobject-introspection you get > > language-bindings for at least JavaScript and Vala out of the box and > > python is planned. There is nothing else to do as the bindings are > > constructed a runtime (vala: compile-time) from the introspection > > files. > > > > > > > > Are the "bindings" the only thing required to properly interface two > > languages together? What about data-type mapping, data marshalling, > > memory management issues, etc? Since we have introspection now, all > > our problems are solved? Correct me if I am wrong but libraries such > > as GJS are meant to handle precisely these issues. > > > > > > But that still is not the main concern of the project; these issues > > are supposed to be handled by specific language plugins (GJS would be > > treated as a language plugin). Moreover as you say, JavaScript support > > is out (GJS) and python support will be complete soon as well > > (PyGObject?). Great, any application can now link to these two > > libraries and use two languages. What if someone writes support for a > > third language, say ruby. Your application will need to be modified to > > use that library and add another dependency. Now libraries to add two > > more languages' support, say Java and .NET, are created. So your > > application will need to add yet more (bloat) code, add another two > > dependencies raising the total number of dependencies to four. Now Lua > > supports comes in... > > > > > > The cycle continues. > > > > I perhaps failed to clearly highlight the main goal of the project: > > enable an application to add scripting support, without regard to any > > particular language, i.e. cross-language. Specific languages plugins > > will then be loaded at runtime (read: no static dependency) which will > > handle all the issues mentioned above plus generate "bindings" via > > GObject-introspection as well. > > > > > > The project is very much inspired by the Kross scripting framework > > which is available to KDE developers ( > > http://www.techbase.kde.org/Kross ) > > So what GObject Introspection gets you is the ability for bindings that > understand GObject Introspection to instantly load those modules and use > them in the language's interpreter. It doesn't instantly allow any app to > load a plugin written in any language. For instance gnome-shell uses the > gjs interpreter and exports functions and objects through GNOME > Introspection. You can't write a python plugin unless the shell decides to > embed a python interpreter. Marshalling data isn't an issue here unless you > wanted to somehow allow different language modules to talk to each other. > > Basically what you would be doing is writing a meta interpreter which would > provide a framework for developers to add plugin support without worrying > about which interpreter they would be using. I see a couple of downfalls to > this approach - specifically security, performance and issues with some > languages not being supported on one or another system. I'm also not > convinced, without a common runtime like .net and given that the client side > of the web has survived pretty well without the need of multiple languages, > it is something we wish to encourage. That being said, the proposal itself > has some merit as a project. > > I wouldn't say its a 'meta interpreter' but yes that is the basic idea. IMO, performance wont be an issue since there will only be a thin layer over the language plugins (which will have interpreters embedded in them). Security can be an issue, but then how does GJS or other existing libraries provide any protection? Besides, there is always the option of introducing some 'restriction mechanism' (if the project becomes mature) such as allowing only "signed" scripts to be executed. The main benefit of supporting multiple languages is more to the users of the application than to its developers. Like I mentioned in my previous mails, if a user wants to add a feature to his favorite application and he knows only a language, say, ruby while the app requires him to write the extension in, say, python then the user is stuck: he has to learn a new language just to write a small piece of code. If I may give an example from proprietary software, Microsoft Access is one major application which suffers from exactly this problem: users are forced to use Visual Basic for Applications (VBA) and many people are simply turned off from having to use it (including this author). The analogy with client-side web scripting is not fair since there were other issues of compatibility, portability, etc involved. Besides, tradiontal web scripting has always involved only one thing namely manipulating DOM for which JavaScript was specifically designed so it was the best choice, anyways. Consider the situation now when things have changed for the web: how many people use JavaScript to write things such as rich interfaces or games? ;-) IMHO, open choice is rarely a bad idea. -- Regards, Shaneeb Kamran
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
