- From: James Hawkins <jhawkins@chromium.org>
- Date: Mon, 12 Mar 2012 13:06:31 -0700
- To: Greg Billock <gbillock@google.com>
- Cc: WebIntents <public-web-intents@w3.org>, Charles Pritchard <chuck@jumis.com>
I'm supportive of the change due to the parallels with the handling of transferables for postMessage. That's not to say I like the solution for either, but I don't see a better solution on the horizon. We should make sure to track this is postMessage and incorporate any changes to the model they make. James On Mon, Mar 12, 2012 at 1:02 PM, Greg Billock <gbillock@google.com> wrote: > Here's how the API would change for transferables: > > [Constructor(in string action, in string type, in any data, in > optional array transferables) raises DOMException] > interface Intent { > readonly attribute DOMString action; > readonly attribute DOMString type; > readonly attribute any data; > > // ONLY PRESENT WHEN THE INTENT IS DELIVERED > readonly attribute array ports; > void postResult (any data, optional array transferables); > void postFailure (any data); > }; > > > On Mon, Mar 12, 2012 at 12:52 PM, Greg Billock <gbillock@google.com> wrote: >> In the draft spec as it is currently [1], there's no allowance for a >> separate parameter to indicate transferables. This was in the hope >> that a more "stately" syntax for including transferables in the >> structured clone algorithm was adopted, and we could use whatever that >> turned out to be. I remarked on the public webapps thread [2] that I >> think we should just plan on appending this argument. Here would be >> the impact: >> >> new Intent(action, type, data, transferables_array) >> >> and in delivery, the Intent object would have a 'ports' field where >> passed ports would be recovered. >> >> For passing transferables in the reverse direction, we'd have >> >> postResult(data, transferables_array) >> >> and in the client, this would translate to >> >> onSuccess(data, ports) >> >> This has the disadvantages and advantages of parallelism with the >> existing transferables uses. >> >> Any opinions or alternatives to consider? I haven't made the 'extras' >> change to the spec yet because this change would be competing for that >> same spot. If there's no objection to adding this transferables array >> argument, I'll add them both at the same time. >> >> >> [1] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html >> [2] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1022.html >> [3] http://lists.w3.org/Archives/Public/public-web-intents/2012Mar/0003.html >
Received on Monday, 12 March 2012 20:07:33 UTC