[whatwg] Proposal for enhancing postMessage

[Mark S. Miller]

Message 2 of 2, from
<http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0002.html>:


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?