Re: Adding fields for transfer map to Intent constructor

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.

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

Is this the way ports are assigned:

client:
i = new Intent("....", "application/x-protocol", port1, [port1]) //
Can port1 even be in data?

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:29:06 UTC