Re: GSoC Proposal: Scripting Framework for Applications

On Tue, 2010-04-06 at 18:24 +0200, Johannes Schmid 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.

If I understand you still need to *load* plugins. While
gobject-introspection do simplify exporting/importing objects (in
runtime or compile time) it does *not* handle loading scripts and
running hooks.

You still need to add support by hand - otherwise there would be no
'javascript only' gnome-shell.

> > 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.

I'm not quite sure how much code/time is spent on this but you still
need to hook the single languages into the stack.

Last time I checked C/python/vala was used. gnome-games seems to use a
bit guile. If user knows lua/ruby/fortran/shell/javascript - he's out of

> > 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".
> BTW, could you explain what components this scripting framework should
> have, which languages it would support, etc.?

I cannot answer for author but I'd imagine that:
 - Searching plugin directories for plugin
 - Detecting the language of plugin (ok. assembler is not the language
plugin is written in but that's different matter).
 - Loading/unloading plugins according to given configuration. Setting
the python/guile/haskell/lua/tcl/brainf*ck/whitespace/javascript
environment. Possibly it should handle dependencies between plugins.

Probably languages should be GModule plugins itself.

I don't know if it is enough for GSOC project but it is at least so
boring task many programs have no more then native+python scripting.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]