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

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.
http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#widl-Intent-data

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.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#internal-structured-cloning-algorithm

Then Web Intents would move the first section of the structured cloning 
algorithm to follow the internal cloning algorithm section, swapping 
their order.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

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:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects

ArrayBuffer is widely implemented. It was the second item to implement 
Transferrable:
http://www.khronos.org/registry/typedarray/specs/latest/#9

Subsequently, ImageData adopted Uint8ClampedArray for one of its 
properties, adopting TypedArrays:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata

This has lead to some instability in the structured clone algorithm for 
ImageData as the typed array object for ImageData is read-only.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13800

ArrayBuffer is still in a strawman state.

-Charles