Mark, I won't pretend to completely understand the use cases you're describing as I'm not familiar with the prior work you've cited. But my understanding of the postMessage() API is that they are primarily useful for handing off ports to new owners - your idea of a pass-by-copy serialization of a proxy object implies that there's some way to copy the message port, and pass that along with the proxy to the new owner, which I don't think is possible in general (you can create a new port as part of a MessageChannel, but you can't really duplicate an existing port).<br>
<br>I may be misunderstanding the use case that's driving your proposal, though.<br><br>-atw<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 7:01 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com">erights@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Message 2 of 2, from<br>
</div><<a href="http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0002.html" target="_blank">http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0002.html</a>>:<br>
<br>
<br>
To be concrete about it, I am a member of the Caja team, which is building<br>
an object-capability subset of JavaScript by translation to JavaScript.<br>
Currently, Caja brings object-capabilities only to intra-frame programming,<br>
but we'd like to extend to inter-frame, inter-worker, and distributed<br>
programming as well. Caja derives for earlier work on E, a distributed<br>
persistent object-capability programming language based on communicating<br>
event loops with promises. We are currently discussing this concurrency<br>
model on the serverjs list as a proposed concurrency model for server side<br>
JavaScript.<br>
<br>
What Caja does for JavaScript, Joe-E does for Java. Tyler Close's ref_send<br>
API adapts E's distribution and concurrency model, and has Joe-E and Caja<br>
compatible implementations <<br>
<a href="http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html" target="_blank">http://waterken.sourceforge.net/javadoc/org/ref_send/package-summary.html</a>> <<br>
<a href="https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p" target="_blank">https://vsci.hpl.hp.com/-/bang/#s=6ysjn2sjvwl35p</a>>. Tyler's Waterken web<br>
server implements ref_send for server side persistent Joe-E apps. So<br>
ref_send currently works fine within a browser frame, between a browser<br>
frame and a server, or between servers. For all the distributed cases, this<br>
works by serializing data to JSON and translating capabilities (object<br>
references) into URLs.<br>
<br>
But a URL cannot be redeemed for an HTML5 MessagePort<br>
or any other access to frame or worker within a browser. Were postMessage<br>
generalized to allow a list of MessagePorts, the capability transmission<br>
portion of ref_send would have a trivial and safe direct mapping onto<br>
inter-frame messages. The only non-obvious part is how to map the promise<br>
for the result of an asynchronous message. But the answer seems simple:<br>
create another MessagePort pair to represent that promise, and send along<br>
with the message the port to be used as the receive side of that pair. I<br>
suspect that many other similar plans would also be enabled by this proposed<br>
enhancement to postMessage.<br>
<br>
Does this make sense? Does it violate some design constraints I might not<br>
know? Is it a good idea?<br>
</blockquote></div><br>