- From: Mark S. Miller <erights@google.com>
- Date: Tue, 10 Mar 2009 19:01:44 -0700
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?
Received on Tuesday, 10 March 2009 19:01:44 UTC