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