On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard <[email protected]
<mailto:[email protected]>> 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
