- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 10 Sep 2012 17:07:14 -0400
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Mitch Zollinger <mzollinger@netflix.com>, public-webcrypto@w3.org
On Sep 10, 2012, at 2:05 PM, Ryan Sleevi wrote: > On Mon, Sep 10, 2012 at 10:31 AM, Mitch Zollinger > <mzollinger@netflix.com> wrote: >> >> What I heard back is as follows: >> >> ... >> But regarding ArrayBuffer / ArrayBufferViews, I think it’s important to >> support Uint8Array (which is an ArrayBufferViews), instead of requiring >> ArrayBuffer. >> >> Whether to support ArrayBuffer as is… it’s a nice to have, since it’s easy >> to “new Uint8Array(ArrayBuffer)”. >> >> Reason I say Uint8Array support is important, because a typical scenario >> looks like this: >> >> 1. Download chunk of data as ArrayBuffer >> 2. Say this chunk is ASN1 encoded array (or any other container)… so when I >> extract IV and CypherText from it… they will be two Uint8Arrays (views) over >> same ArrayBuffer. >> 3. If Uint8Arrays is not supported, one will need to make copies of portions >> of original ArrayBuffer… >> ... >> >> HTH, >> Mitch > > Thanks Mitch. That confirms what my thought had been in favouring > ArrayBufferView. > > I think we can also address the ArrayBuffer v ArrayBufferView by > revisiting the support for Blob - which also supports copy-free > slice()-ing and can save an indirection through a FileReader. > I've come around to this. The copy semantics pose limitations. And, I polled Mozilla's Jonas Sicking, Boris Zbarsky, and Ben Turner, and they agree. From Jonas: "[ ] I suspect that the API should support both ArrayBufferViews and Blobs." Support for ArrayBufferView gives us Uint8Array and others. -- A*
Received on Monday, 10 September 2012 21:07:44 UTC