Re: Web Crypto Spec Updates for ArrayBufferView, ArrayBuffer, and Streams

On Fri, Apr 26, 2013 at 7:09 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> ARRAY BUFFER
>
>
>
> Per our conversation during the F2F.  ArrayBufferViews are useful to when
> you want to access parts of the information inside an ArrayBuffer.  If you
> are going to be consuming the ArrayBuffer directly, it doesn’t make sense to
> create ArrayBufferViews.  Here are some examples of APIs that directly
> generate ArrayBuffers or consume it:
>
>
>
> * XHR return type can be an ArrayBuffer --> XMLHttpRequestResponseType of
> ArrayBuffer
>
> * Blob constructor (takes both ArrayBuffer or ArrayBufferView)
>
> * Blob readAsArrayBuffer returns an ArrayBuffer

Right - I have to keep up with stalking Arun's bugs.

Blob started as ArrayBuffer, then switched to ArrayBufferView (along
with XHR.send()) in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16732

However, overloaded support for ArrayBufferView was restored back in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18668 , as a result of
https://bugzilla.mozilla.org/show_bug.cgi?id=752402

If you examine that bug, you will see that decision was in part based
on the fact that IE10 was shipping with Blob supporting ArrayBuffer in
the constructor. I don't think we have the same limitations here, so I
think we want to be careful when using Blob as a justification for the
change.

For example, XHR.send() continues to only take an ArrayBufferView -
see http://xhr.spec.whatwg.org/#the-send()-method - and the
ArrayBuffer overload is something we've deprecated in Chrome ( see
http://updates.html5rocks.com/2012/07/Arrived-xhr-send-ArrayBufferViews
)

I think we should also be careful when distinguishing between
*generating* and *returning* an ArrayBuffer. I agree that it may make
sense to update result to be an explicit ArrayBuffer, but I'm less
convinced on the overloads for inputs, given the other API
discussions.

>
> * MSE appendBuffer(ArrayBuffer)
>
>
>
> Overloading the existing methods to directly consume ArrayBuffer, in
> addition to ArrayBufferView, provides more flexibility and simplifies the
> programming model for developers who are looking to use the ArrayBuffer
> content directly.
>
>
>
> Like I mentioned during our F2F, the purpose of this suggestion was to
> simplify the programming model.  I’m not as passionate on this topic because
> our engine internally manages both ArrayBuffer and ArrayBufferView inputs
> the same way.
>
>
>
> STREAM
>
>
>
> As we also discussed in the F2F, the use of streams enables many useful
> scenarios and the existing event model can be nicely incorporated to provide
> progress events.  We agreed that streams enables the support of needed uses
> cases to reduce number of buffer copies and increase performance.  Streams
> are currently supported in the MSE and XHR:
>
>
>
> *  SourceBuffer.appendStream (Stream stream, optional unsigned long long
> maxSize);
>
> * XHR return type can be an stream --> XMLHttpRequestResponseType of stream
>
>
>
> Also, my understanding from Ryan was that Chrome is working on a stream’s
> implementation.  If we are considering making fundamental changes to the
> spec this late in the game to include things like Future then this seems
> like a reasonable addition given there are concrete use cases for it and a
> more stable spec for it ;-).

I would suggest Futures is probably far less reaching than Streams,
for the reasons discussed and explored at
http://www.w3.org/2012/webcrypto/track/issues/18

The primary reason that I see it as less-fundamental is that the
current API is already modeled after 'success'+result/'failure' - a
concept easily modeled by Futures.

Streams is a much more significant conceptual shift in design, at
least with respect to *vending* a Stream - perhaps as much as to
suggest a fundamentally different API.

That is, the current API conceptually models elements of both a Stream
(eg: the nature of result) and a StreamBuilder (eg:
CryptoOperation.process() ~= StreamBuilder.append() ,
CryptoOperation.finish() ~= StreamBuilder.close() )

Streams are also somewhat troubling because, as defined in
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#streambuilder-interface
, Streams have a content type, whereas CryptoOperations do not. For
most use cases of crypto, this adds additional caller overhead to
(perhaps redundantly) indicate the type if application/octet-stream.
Additionally, Streams may be used with URL.createObjectURL() - which
has a whole host of issues that have yet to be addressed in the File
API, but carry with it significant security / performance
considerations when applied to Crypto.

I'd like to detach the Streams proposal from the
ArrayBuffer/ArrayBufferView discussion, to make sure that we can
adequately discuss both issues, but it certainly seems like if we were
to make changes in the first version, ArrayBuffer/ArrayBufferView is
much more tenable than Streams.

Received on Saturday, 27 April 2013 02:38:19 UTC