Re: [whatwg] Proposal for enhancing postMessage
On Wed, Mar 11, 2009 at 2:30 PM, Drew Wilson atwil...@google.com wrote: 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). I may be misunderstanding the use case that's driving your proposal, though. And I may be misunderstanding the postMessage draft spec. But step 4 of 7.4.4 at http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages-with-message-ports reads: Try to obtain a new port by cloning the messagePort argument with the Window object on which the method was invoked as the owner of the clone. If this returns an exception, then throw that exception and abort these steps. Doesn't this mean that sending a MessagePort actually sends a clone? -- Cheers, --MarkM
Re: [whatwg] Proposal for enhancing postMessage
Yes, it sends a clone, but the source port becomes unentangled (inactive) - step 5 of the clone a port specification reads: Entanglehttp://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#entangle the remote port and new port objects. The original port object will be unentangled by this process. So, cloning a port has the effect of killing the original port - the intent, I think, is for the sender to permanently hand off ownership of the port to the recipient, not to duplicate the port itself. I think this is a side issue, though - I agree that since you can effectively pass a message consisting of multiple objects, you probably ought to be able to pass multiple MessagePorts along with them. As you point out, it's primarily a matter of convenience/efficiency - you could still get the same functionality by individually serializing each object/port pair. -atw On Fri, Mar 13, 2009 at 2:06 PM, Mark S. Miller erig...@google.com wrote: On Wed, Mar 11, 2009 at 2:30 PM, Drew Wilson atwil...@google.com wrote: 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). I may be misunderstanding the use case that's driving your proposal, though. And I may be misunderstanding the postMessage draft spec. But step 4 of 7.4.4 at http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages-with-message-ports reads: Try to obtain a new port by cloning the messagePort argument with the Window object on which the method was invoked as the owner of the clone. If this returns an exception, then throw that exception and abort these steps. Doesn't this mean that sending a MessagePort actually sends a clone? -- Cheers, --MarkM
Re: [whatwg] Proposal for enhancing postMessage
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?
