- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 Sep 2013 17:07:15 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369 Joshua Bell <jsbell@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |23332 --- Comment #2 from Joshua Bell <jsbell@google.com> --- Marking as "blocks https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332" since if we decide anything here it will change how that API should be defined. It's another "operation needs a byte sequence" API, like encoding. Agreed w/ BZ that we do not need new syntax/names here. It seems to me that we should agree on what this (growing?) class of operations should accept so they are consistent. In these APIs, the type of the view is unimportant and potentially misleading - if a caller passes a Float32Array the floats are ignored and just the underlying bytes are used. A few possibilities: #1: operation( (ArrayBuffer or ArrayBufferView) byteSequence ); #2: operation( ArrayBuffer byteSequence ); #3: operation( ArrayBufferView byteSequence ); #4: operation( DataView byteSequence ); #5: operation( Uint8Array byteSequence ); #6: operation( (ArrayBuffer or Uint8Array) byteSequence ); #1 lets you pass in a buffer or a view on a buffer. https://bugzilla.mozilla.org/show_bug.cgi?id=796327 indicates window.ArrayBufferView is being removed (which would complicate polyfills) and ArrayBufferView is not in the ES6 drafts. Can it still be used in IDL? If not this would need to become a union of all the array types i.e. (Int8Array or Uint8Array or Uint8ArrayClamped or Int16Array or ... or Float64Array). #2 forces the caller to have a raw "array of bytes". If operating on a subset of a larger buffer this requires a copy. Bleah. #3 is possibly problematic for the same reasons as #1. (FWIW, this is what TextDecoder accepts today) #4 uses the type-agnostic DataView, most commonly used for encoding/decoding structs/files. In the abstract this seems more correct than many of the other options, but it's one more concept for developers to learn. #5 anoints Uint8Array as "this is a byte sequence". It's akin to saying "in this C++ project, a we hold a sequence bytes in a std::vector<unsigned char>", for the web platform. (And I'm okay with that, but others may object) #6 is a slight compromise on #5 that avoids having to new Uint8Array(buffer) if you already have an ArrayBuffer from another source. This seems like API clutter to me. If we e.g. agree on #5 for this class of APIs then we don't need anything new in IDL - it's Uint8Array in and out from these operations. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 26 September 2013 17:07:20 UTC