Re: MessagePorts and postMessage(message, port)

[+e-lang, +google-caja-discuss, +serverjs]

On Fri, Mar 6, 2009 at 8:36 PM, Mark S. Miller <[email protected]> wrote:

> Hi,
>
> Currently, HTML5's postMessage may transfer some amount of data in the
> message, and up to one MessagePort as the port parameter. I propose that
> postMessage be modified to allow an array of MessagePorts to be transferred.



Should I read the lack of response as no interest? no comprehension? no
objections? no inclination to take this seriously since it is too late?

To be concrete about it, I am a member of the Caja team, which is building
an object-capability subset of JavaScript by translation to JavaScript.
Currently, Caja brings object-capabilities only to intra-frame programming,
but we'd like to extend to inter-frame, inter-worker, and distributed
programming as well. Caja derives for earlier work on E, a distributed
persistent object-capability programming language based on communicating
event loops with promises. We are currently discussing this concurrency
model on the serverjs list as a proposed concurrency model for server side
JavaScript.

What Caja does for JavaScript, Joe-E does for Java. Tyler Close's ref_send
API adapts E's distribution and concurrency model, and has Joe-E and Caja
compatible implementations <
http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html> <
https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p>. Tyler's Waterken web
server implements ref_send for server side persistent Joe-E apps. So
ref_send currently works fine within a browser frame, between a browser
frame and a server, or between servers. For all the distributed cases, this
works by serializing data to JSON and translating capabilities (object
references) into URLs. But a URL cannot be redeemed for an HTML5 MessagePort
or any other access to frame or worker within a browser. Were postMessage
generalized to allow a list of MessagePorts, the capability transmission
portion of ref_send would have a trivial and safe direct mapping onto
inter-frame messages. The only non-obvious part is how to map the promise
for the result of an asynchronous message. But the answer seems simple:
create another MessagePort pair to represent that promise, and send along
with the message the port to be used as the receive side of that pair. I
suspect that many other similar plans would also be enabled by this proposed
enhancement to postMessage.

Does this make sense? Does it violate some design constraints I might not
know? Is it a good idea?

-- 
   Cheers,
   --MarkM