[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sashxb-discussion
Subject:    Re: [Sashxb-discussion] the long awaited runtime rewrite ...
From:       Thomas M Capasso <tcapasso () andrew ! cmu ! edu>
Date:       2001-04-17 21:23:45
[Download RAW message or body]

Sorry about the previous one. I pressed the wrong button.

On Tue, 17 Apr 2001, Ari Heitner wrote:

> 
> Hi random people,
> 
> Over spring break (already a couple weeks ago) I was back in Cambridge
> hacking for the Man. I was working on the rewrite of the SashXB runtime side
> to be purely XPCOM/XPConnect based, getting rid of the evil evil marshalling
> stuff and backend JS-engine interface left over from the first version of
> Sash/Linux. This changeover isn't quite complete, but it's very
> straightforward and I expect to be done in a few weeks, well before the
> beginning of XB this summer. John and AJ and Jordi: I expect the new version
> of the runtime to be firmly in place and all (or most) of the existing
> locations/extensions to be ported over.
> 
> Background: the initial version of the Sash runtime was the infrastructure
> that existed as of the beginning of XB '00, now found in the sash/ subdir.
> This code talks to Brendan Eich's JavaScript engine from the back end,
> embedding the "Sash.*" namespace (i.e. allows the extensions/locations to
> expose their functionality to JS) in the browser's DOM. Realistically, this
> code is 5000 lines of cruft (read it some time if you don't believe me) that
> no one wants to use or maintain. The way extensions must insert themselves
> into the JS engine now involves all sorts of evil -- static data structures,
> magic wrapper code generated with PERL, etc etc.
> 
> We also all know that Mozilla has the magic of XPCOM and XPConnect, and can
> automagically marshal objects and interfaces between its supported
> languages. The direction that's important to us is C++ -> JS. Basically what
> the new version of the Sash runtime does is automatically marshall the
> extension interfaces into JS.
> 
> I'm not going to talk about the technical details of how this works. Suffice
> to say it's pretty simple -- you register the objects with XPCOM, and you
> can then instantiate them in JS and glue them together into a familiar
> top-level Sash object and its subcomponents. Basically the interaction
> between the runtime itself and the extension interface (there is a new
> sashIExtension and sashILocation that locations/extensions must implement;
> this replaces the old C module interface) is the extension returns a few
> magic strings: an interface name (the Filesystem extension might return
> "sashIFilesystem") and an implementation name
> ("@gnome.org/SashMo/filesystem" -- this is equivalent to a CLSID uuid, the
> uuid indentifying a specific implementation of an interface).
> 
> Tom wrote up a bunch of docs on this stuff that he promises he'll have done
> and forwarded to you guys before he leaves to join the processor design
> people in Austin ...
> 
> The one part of the story that *won't* be done is security for this stuff --
> you can do evil things with XPConnect. But Mozilla *does* have the hardware
> to make this all work. I talked about this all with John Bandhauer (the
> Mozilla XPCOM guy) and it's all on record in mozilla-xpcom somewhere. I'll
> go find it for you guys later.
> 
> One other note: my GNOME CVS access died, so none of my current stuff is
> checked in yet. I'll work on getting it all in soon.
> 
> I have a request of Tom, John, AJ, and pretty much any other
> sashxb-developers guys who are taking this: send me a ping back so I know
> who's seen this.
> 
> Of course anyone on sashxb-discussion who has any other questions, just mail
> the list back and I'll be glad to answer.
> 
> 
> Ari
> 
> 
> _______________________________________________
> Sashxb-discussion mailing list
> Sashxb-discussion@www-124.ibm.com
> http://www-124.ibm.com/developerworks/opensource/mailman/listinfo/sashxb-discussion
> 


[prev in list] [next in list] [prev in thread] [next in thread]