Native modules

Kam Kasravi kamkasravi at yahoo.com
Wed Jan 20 00:44:32 PST 2010


I had approached this concept in a slightly different way where resources required were 
specified using a derived MessageEvent type. There is precedence in 
building from the event system since its the only place I'm aware of where 
distributed semantics are being formally broached -eg postMessage, MessageChannels, etc.
So motivations could be:
1) Already a rich hierarchy of DOM events  
2) MessageEvent, postMessage, onMessage has good support across browsers
3) Security is factored into postMessage with remote or cross-document messaging.
4) MessagePorts are queued, providing well-defined dependency ordering

I had also used WebSockets (supported in Chrome and Webkit). Also supported in Jetty
and a few other servers.WebSockets can be emulated in other browsers via flash. 
Although this is delving too deep into implementation details, describing resources required 
within a derived MessageEvent like ResourcesRequest and ResourcesResponse with 
the ability to send related info per request like if-modified-since would allow a server to 
respond with a ResourcesResponse that included aggregated content (images,css,js) specified in the 
ResourcesRequest. Done over a websocket, it would satisfy Ihab's suggestion to do this 
over a devoted bidirectional channel which is the WebSockets protocol. Performance characteristics 
especially if you use the gmail technique of delaying eval of javascript sources until needed were 
very convincing.Is this forum appropriate for discussion of eventing, WebIDL, etc? I'm not sure, though 
I imagine this committee has spent uncountable hours discussing events related to the DOM etc.


kam

                                 






________________________________
From: "ihab.awad at gmail.com" <ihab.awad at gmail.com>
To: Kevin Curtis <kevinc1846 at googlemail.com>
Cc: es-discuss at mozilla.org
Sent: Tue, January 19, 2010 11:46:56 AM
Subject: Re: Native modules

On Tue, Jan 19, 2010 at 11:26 AM, Kevin Curtis
<kevinc1846 at googlemail.com> wrote:
> Could a ECMAScript module proposal cover 'native modules' - which are built
> into the platform (ECMAScript engine and browser) - and can be imported if
> required and are not a binding on the global object. Could be useful for
> vendor specific innovation.


More information about the es-discuss mailing list