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

I agree, we should decouple the ArrayBuffer issue from the Streams issue.  More comments inline.

On Friday, April 26, 2013 7:38 PM, Ryan Sleevi wrote:
> 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
> )

At the end of the day, I'm not religious about whether we overload the methods to support ArrayBuffer.  
Like I said, it just makes it easier for developers to be able to directly use the return values from XHR and, yes even, Blobs without having to create 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.
> 

I'm glad that we agree on the return type :-)

> >
> > * MSE appendBuffer(ArrayBuffer)
> >

I noticed that you didn't address the use of ArrayBuffer overloads on MSE as part of your argument.

> >
> >
> > 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.

I believe it would be good to verify now if the proposed model is not able to evolve to support Stream in the future.  All I'm suggesting is that we explore Stream and verify that the current model will be able to support them in the future.  It they are not that different, we can consider including them in the spec now.  If they are different, we should consider making changes to the existing model to support Stream in the future.

> 
> 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() )

I believe there is a model where Streams and ArrayBuffers can be used together to deliver information to the crypto operations.  I'm not sure that a CryptoOperation.finish() == StreamBuilder.close().  I would like to explore the possibility of having a CryptoOperation be used to process multiple ArrayBufferViews and Streams simultaneously.

> 
> 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.

This seems like a great opportunity to move those concerns forward.

> 
> 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.
> 

Thanks,

Israel

Received on Thursday, 2 May 2013 06:29:32 UTC