[whatwg] Proposal for enhancing postMessage

[Drew Wilson]

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.

-atw

On Tue, Mar 10, 2009 at 7:01 PM, Mark S. Miller <erights at google.com> wrote:

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090311/87a714a1/attachment-0002.htm>