[+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
