W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 05 Mar 2012 18:46:18 -0800
Message-ID: <4F557A7A.9080200@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Feras Moussa <ferasm@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>
On 3/5/2012 5:56 PM, Glenn Maynard wrote:
> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>     Do you see old behavior working something like the following?
>     var blob = new Blob("my new big blob");
>     var keepBlob = blob.slice(); destination.postMessage(blob, '*',
>     [blob]); // is try/catch needed here?
> You don't need to do that.  If you don't want postMessage to transfer 
> the blob, then simply don't include it in the transfer parameter, and 
> it'll perform a normal structured clone.  postMessage behaves this way 
> in part for backwards-compatibility: so exactly in cases like this, we 
> can make Blob implement Transferable without breaking existing code.
> See http://dev.w3.org/html5/postmsg/#posting-messages and similar 
> postMessage APIs.

Web Intents won't have a transfer map argument.

For the Web Intents structured cloning algorithm, Web Intents would be 
inserting into step 3:
     If input is a Transferable object, add it to the transfer map.

Then Web Intents would move the first section of the structured cloning 
algorithm to follow the internal cloning algorithm section, swapping 
their order.

That's my understanding.

Something like this may be necessary if Blob were a Transferable:
var keepBlob = blob.slice();
var intent = new Intent("-x-my-intent", blob);
navigator.startActivity(intent, callback);

>     And we might have an error on postMessage stashing it in the
>     transfer array if it's not a Transferable on an older browser.

Example of how easy the neutered concept applies to Transferrable:
> var blob = new Blob("my big blob");
> blob.close();

I like the idea of having Blob implement Transferrable and adding close 
to the Transferrable interface.
File.close could have a better relationship with the cache and/or locks 
on data.

Some history on Transferrable and structured clones:

Note: MessagePort does have a close method and is currently the only 
Transferrable mentioned in WHATWG:

ArrayBuffer is widely implemented. It was the second item to implement 

Subsequently, ImageData adopted Uint8ClampedArray for one of its 
properties, adopting TypedArrays:

This has lead to some instability in the structured clone algorithm for 
ImageData as the typed array object for ImageData is read-only.

ArrayBuffer is still in a strawman state.

Received on Tuesday, 6 March 2012 02:46:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:48 UTC