- From: Greg Billock <gbillock@google.com>
- Date: Mon, 12 Mar 2012 14:00:19 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Paul Kinlan <paulkinlan@google.com>, James Hawkins <jhawkins@chromium.org>, WebIntents <public-web-intents@w3.org>
Note: Web Messaging: http://dev.w3.org/html5/postmsg/ specifically: http://dev.w3.org/html5/postmsg/#posting-messages See also the structured clone algorithm: http://dev.w3.org/html5/spec/common-dom-interfaces.html specifically: http://dev.w3.org/html5/spec/common-dom-interfaces.html#transferable-objects Charles, I'm interpreting those documents as saying that the preferred usage for ports is now postMessage(port, [port]); which is what I'm proposing we require for web intents, as opposed to postMessage(null, [port]); or even the older postMessage(null, port); is that right? Basically what I want to do is have the arguments in place to support the messaging standard, but further to require the current recommendation from the start. Ultimately, I do think it would be nicer on the receiving end to simply be able to walk the payload data and get any transferables that have come through, rather than needing to retrieve ports from a separate array. I think this is already going to be true for ArrayBuffer types, but ports are still getting some special treatment. Is that also your sense of where the evolution is going? In that world, we would be supporting the 'ports' field for some time, but we'd at that point move to also making all transferables available in the structured clone payload as well. I think that the interface I'm suggesting is pretty friendly to that evolution. On Mon, Mar 12, 2012 at 1:46 PM, Charles Pritchard <chuck@jumis.com> wrote: > On 3/12/2012 1:39 PM, Paul Kinlan wrote: >> >> So does this mean that .ports will be populated by iterating through >> the transferable array and looking to see if it is a MessagePort or >> not? >> >> Sorry if this seems dense, but if we are passing the ports in data >> (and transferable array), then we should access it on intent.data and >> thus remove any need for .ports > > > Instead of inventing, we're using the structured clone algorithm and the Web > Messaging spec as they are written. > > There was [well-reasoned] push-back on inventing or altering the current > structured clone algorithm. > Though MessagePort is stable/mature, ArrayBuffer is not. > > When you have a message port open, you can send more ports through it. > Authors would use extras when sending files and/or metadata, they'd use > transfer when opening a protocol. > > > -Charles
Received on Monday, 12 March 2012 21:00:48 UTC