Re: Adding fields for transfer map to Intent constructor

On Mon, Mar 12, 2012 at 1:28 PM, Paul Kinlan <paulkinlan@google.com> wrote:
> My personal preference is to assume transferable and automatically
> populate the transfer array (thus removing it).  I am not keen on the
> transferable array, and I am not sure how this solves message port, I
> don't see a way to assign ports.

This is how ports are passed through postMessage (modulo other cases
where you can, for instance, do postMessage(null, port) and stuff like
that, but those are hopefully all deprecated).




>
> In this model ports is only set when delivered (for which I don't
> understand why).

In postMessage, your MessageEvent has the 'ports' property with the
ports in it (they don't come in in the corresponding spots in the
payload where you set them). I think this is a wart on the spec, which
is what I meant by having both the advantages and disadvantages. :-)
Maybe Charles can comment on the current thinking there.

>
> Is this the way ports are assigned:
>
> client:
> i = new Intent("....", "application/x-protocol", port1, [port1]) //
> Can port1 even be in data?

In this spec, it must be, yes. I believe this matches the current
desired behavior for how transferables and structured clone interact,
but Charles can confirm.

> service:
> if(window.intent && window.intent.port) {
>    port.onmessage = function() {}
> }
>
> Why not just use data?
>
> P
>
> On Mon, Mar 12, 2012 at 8:06 PM, James Hawkins <jhawkins@chromium.org> wrote:
>>
>> 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
>> >
>>
>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan

Received on Monday, 12 March 2012 20:33:34 UTC