Re: GSoC Proposal: Scripting Framework for Applications

[John Palmieri <johnp redhat com>]

----- "Shaneeb Kamran" <shaneebster gmail com> wrote:

> On Tue, Apr 6, 2010 at 9:24 PM, Johannes Schmid < jhs 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.

--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.