- From: <bugzilla@jessica.w3.org>
- Date: Mon, 09 Jun 2014 06:09:41 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369
Ryan Sleevi <sleevi@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sleevi@google.com
--- Comment #13 from Ryan Sleevi <sleevi@google.com> ---
Another reason to place this in WebIDL: Currently, when dealing with
Promise-returning specifications, it's ambiguous about how
ArrayBuffer/ArrayBufferView data is handled.
That is, the naive approach - "Return a Promise and continuing executing these
steps asynchronously" (as recommended by
https://github.com/w3ctag/promises-guide ) doesn't quite work, because it
allows the script environment to manipulate the underlying bytes while the
Promise-d operation continues.
Both WebCrypto and WebAudio have had to define how to do this, and in slightly
different ways. WebAudio pursued an (invalid) approach of 'temporarily neuter',
while WebCrypto pursued a path of 'copy'. Other paths discussed in WebCrypto
were 'permanently neuter' (aka, Transferrable) or 'copy on write' (ruled out by
implementors as complexity/performance overhead for the common case of
ArrayBuffers)
It's unclear whether or not WebIDL should have annotations to support this
special-case, or whether all specs should pursue one or the other. I would
expect that, since ArrayBufferViews are seen as valid inputs, a 'copy' approach
is desirable for consistency, but I can see specs needing to annotate
transferrable.
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 9 June 2014 06:09:43 UTC