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 two uses-cases I mentioned are similar to what you are suggesting.
> In my opinion, these two extremes do seem to have a fair bit of
> similarity and hence they can be supported using a single scripting
> framework. Moreover, attempting to unify them would save some code
> bloat since a single solution is always better than two overlapping
> ones.
Well, would a single solution have so much benefit? Of course you might
be able to unify the way plugins are loaded and plugin descriptions are
designed but this is actually not much code as most things a handled by
GModule anyway.
Much more important is the point that any application has it's own
plugin API anyway, as the plugins have to interact with the internal
architecture of the application.
Example: gedit and anjuta both use gtksourceview. But a plugin in gedit
is able to interact directly with the gtksourceview class while anjuta
supports different editors and as such has an interface called
IAnjutaEditor which is used to interact with the editor. A unified
framework won't help you here at all.
Covering the two use cases (plugin + embedding) is not the main focus of the project. Let me rephrase it as covering the 'maximum possible usage scenarios'. If its not possible to unify embedding and plugin usages then let it be so; I will not attempt to cover both usages in such a case ;-) ... My point was that we shouldn't restrict ourselves to only a single use case but rather make it as general as possible. Plus I wanted to make a stronger case for my proposal ... ;-)
> You reinforced my point ;-) . Having a proper scripting framework
> would avoid having to modify/update each application individually in
> order to support any new technology in future. Same goes if for
> example, as you say, python bindings become more mature: individual
> applications would not have to be updated to add support for this new
> language.
>
See above. The internal APIs need to be exposed anyway and
gobject-introspection is the best way to do it. I wonder what would be
left for the "Scripting Framework".
If your not happy with "framework", suggest a word you like better. I only used it since the KDE folks call their implementation (Kross) a 'scripting framework' so I just reused that phrase. And maybe you are right, its not a complete framework in its own right without the backend language plugins.
BTW, could you explain what components this scripting framework should
have, which languages it would support, etc.?
There will be two components:
1) The top-level main 'framework' (or whatever you want to call it), which provides a single, unified API to applications to add language-independent scripting support. This layer will handle dynamically locating and loading language plugins and passing scripts from the application to the interpreters via them. (Some memory management issues across plugins might need to be handled at this layer as well).
2) The language plugins, which do the language-specific interfacing tasks including bindings generation, data marshalling, memory management, etc.
If this is small for a GSoC project then other related tasks can be added too. This might include wrapping existing GJS, PyGObject libraries as plugins, creating language plugins for other languages such as Java, .NET or Ruby, etc. This will enable a complete solution to be made ready by the end of SoC and hence will be immediately available to applications to use.
