Re: Adding fields for transfer map to Intent constructor

On Mon, Mar 12, 2012 at 1:39 PM, Paul Kinlan <paulkinlan@google.com> 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?

Internally it's more intricate than that, but from the javascript
side, yes, it looks like the machinery is looking through the transfer
map argument, pulling out the ports, and putting them into 'ports'.

> 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

Agreed, but I don't think that's how structured clone and
transferables work currently. Charles may have more info on the
current and imagined behavior.

> P
>
> On Mon, Mar 12, 2012 at 8:33 PM, Greg Billock <gbillock@google.com> wrote:
>> 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
>
>
>
> --
> 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:43:37 UTC