[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #24 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Allen Wirfs-Brock from comment #23)
> Does it matter which cipertext was processed.  The caller was adequately
> warned that they were invoking an async operation which they acknowledged by
> explicitly coding a 'then' call.  They went ahead and did something stupid
> anyway.  Do we really need to be nannies protecting them from their
> stupidity. Is it worth the copying overhead for the vast majority of
> non-stupid callers who don't do stupid things like this?  So far, at least
> for these two operations it doesn't look like its an integrity issue.

I don't know what you mean by "an integrity issue". Modifying a buffer during
verify, for example, can cause a different message to be verified than
intended. Modifying a message during decrypt might allow an invalid message to
be treated as valid, thus causing all sorts of cryptographic bugs.

This is not about being nannies. This is about being responsible spec authors
and defining sensible memory models and pseudo-threading semantics, rather than
being blaise and saying "Don't do that". The term "undefined behaviour" should
be the last refuge of the spec author, not the first.

> well, neither %TypedArray% or Array are primitive in the same sense as
> Number, Boolean, Number in ES6. But I agree that handling of %TypedArrays%
> has a place within WebIDL.  I don't think either Array or %TypedArray%
> instances should be routinely copied as part of the WebIDL parameter passing
> mechanism.

And again, I'm not arguing that all %TypedArray% parameters should be copied.
I've merely requested for the capability of indicating when a copy should
happen.

It's clear from multiple specifications (Web Audio and Web Crypto at the
forefront), that spec authors and users both have a desire to have reliable,
known access patterns for data; patterns that conceptually align with the
access patterns synchronous APIs provide, and patterns that encourage
consistency across specs.

An annotative capability, for example, much like [TreatNullAs], does provide a
consistent way for specifications to indicate certain behaviours, and authors
to rely on them.

I'm not sure what use cases you have in mind that would benefit from this, or
what design objections you have to the concept of copying, but I think the
feedback and experience of implementers so far is that 'copying' is what makes
sense for a number of reasons. I can't help but feel like if there is a use
case for 'mutable-while-running', it's almost certainly a case that is better
served by things like the nascent Streams API (
https://github.com/whatwg/streams ).

As it relates to Web IDL specifically - rather than, I think, some of the
discussion here that might be better on public-script-coord@ - having Web IDL
support TypedArray - as indicated in this bug report - and a way to indicate
what behaviours/treatment the underlying buffer are given, would be useful to
authors and users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 18 June 2014 00:07:25 UTC