Re: Module semi-proposal: gnome-shell

[Jamie McCracken <jamie mccrack googlemail com>]

JS, whilst a good glue language, is nevertheless problematic in this it
appears impotent (no native dbus support nor subclassing). I would only
recommend it for scripting that does not need dbus. Currently a lot of
code needs to be written in C to make up for these shortfalls in
Gnome-Shell so I dont think its a particular good choice. I dont however
see it as a blocker to gnome-shell acceptance

A much better alternative to any VM out there is Vala which sports two
languages (Genie being a python/Delphi as well as Vala's c#/java syntax)
and which gives C like performance and is moulded to fit gobject and our
platform perfectly with better Dbus integration

jamie


On Wed, 2009-11-04 at 13:04 -0500, Owen Taylor wrote:
> On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote:
> 
> > 2009/11/2 Owen Taylor <otaylor redhat com>:
> > >  GJS and SpiderMonkey: Currently gnome-shell is build using the
> > >    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
> > >    Javascript engine. The comparison to seed/JavascriptCore has been
> > >    discussed quite a bit in the past, I don't want to go into in
> > >    detail here; basically the advantages for us are:
> > 
> > I have not been following the GNOME shell discussions, but I wonder
> > why we JavaScript is needed at all. Now that some of the core modules
> > exhibit Python, suddently JavaScript is discussed. I have always
> > considered programming and script languages as interchangeable
> > (besides syntactic and refactoring sugar), so we need a good argument
> > for adding new ones that just make the dependency stack larger and
> > larger. I'd really strongly opt for "C + Mono + one scripting
> > language" or "C + Mono" or "C + one scripting language" when we talk
> > about the core desktop. I see no advantage whatsoever in a Babylonian
> > approach -- unless you convince me with good arguments.
> 
> The most fundamental and core reason for the use of Javascript is
> that it gives us a clean platform; the experience with Javascript is
> that you get a very pure experience with the GNOME libraries - to do IO,
> you use GIO, and so forth. There are other languages where this
> would be the case (Lua for example), but it's not the case with
> Python, Mono, etc which have large standard libraries that overlap
> with the GNOME libraries in complicated ways.
> 
> There are a number of secondary reasons, among them:
> 
>  - Familiarity - Python is certainly widely known, but not as
>    widely as Javascript, Javascript provides an opportunity to
>    get more people involved with GNOME.
> 
>  - Performance; JIT compilation is more advanced and widely
>    deployed for Javascript than for Python, there's a lot of
>    competition going on currently on performance for open-source
>    Javascript engines.
> 
>  - Sandboxing - not a huge concern at the moment; we're more
>    interested in extensions that have unrestricted access to
>    the shell and platform than constrained widgets, but there
>    are possibilities opened up by the ability to have an
>    interpreter running in a restricted context, something that
>    there's a lot more experience with with Javascript than
>    any other language.
> 
> In terms of "C + Mono" - well, that's certainly a discussion I don't
> want to get into, but practically speaking, for whatever, reason, there
> is is no use of Mono in the core of the GNOME desktop, though there
> are several applications built with Mono as part of the release sets.
> 
> > >    In one sense SpiderMonkey is not a problematic dependency;
> > >    SpiderMonkey is distributed as part of xulrunner, and will be
> > >    present on virtually any computer where GNOME is available.
> > 
> > Now that both the Epiphany web browser and Yelp [1] moved away  from
> > Gecko to WebKit, it seems to be very odd that we suddently introduce a
> > XULrunner dependency again. Is this a political decision due to the
> > collaboration of the GNOME foundation and the Mozilla foundation that
> > was once announced?
> 
> The reason that we went with GJS (and thus SpiderMonkey) when we
> started was that at point it was more mature than Seed and maintained by
> people that we knew better (like Havoc and Johan). Seed quickly made
> progress and surpassed GJS in the feature set, and we got to know Rob
> and Tim well too, but there's never been a choice where making a switch
> from one to the other has seemed like a good use of resources.
> 
> There are ways that SpiderMonkey is better technically aligned with what
> we are doing with the Shell ... after all, its being used as the core of
> a large hybrid native/Javascript application, instead of just inside web
> pages. So, there's more control over garbage collection, and more of a
> willingness to add language extensions. There's very little interest
> from the WebKit to add language extensions because they aren't usable
> from web pages, which are by definition cross-browser.
> 
> But the main thing is just history and priorities.
> 
> I would emphasize that the choice of Javascript engine is largely just
> not that important. We don't have any code written directly to the
> SpiderMonkey C apis; everything is intermediated through
> gbject-introspection. The syntax for imports and for using GObjects is
> the same between GJS and Seed. We do use a number of SpiderMonkey
> extensions extensively, but removing the use would be straightforward
> and mechanical. If switching makes sense, we can switch at any point.
> 
> - Owen
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list