[+e-lang, +google-caja-discuss, +serverjs]<br><br>On Fri, Mar 6, 2009 at 8:36 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com">erights@google.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br><br>Currently, HTML5's <span style="font-family: courier new,monospace;">postMessage</span> may transfer some amount of data in the <span style="font-family: courier new,monospace;">message</span>, and up to one MessagePort as the <span style="font-family: courier new,monospace;">port</span> parameter. I propose that postMessage be modified to allow an array of MessagePorts to be transferred.<font color="#888888"></font></blockquote>
<div><br><br>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?<br><br>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. <br clear="all"><br>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 <<a href="http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html">http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html</a>> <<a href="https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p">https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p</a>>. 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.<br>
<br>Does this make sense? Does it violate some design constraints I might not know? Is it a good idea?<br></div></div><br>-- <br> Cheers,<br> --MarkM<br><br>