Re: Adding fields for transfer map to Intent constructor

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:02:39 UTC