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

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
* 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 ;-).

Israel

On Tuesday, April 23, 2013 9:06 AM Aymeric Vitte wrote:
Le 23/04/2013 16:03, Ryan Sleevi a écrit :

On Apr 23, 2013 6:48 AM, "Aymeric Vitte" <vitteaymeric@gmail.com<mailto:vitteaymeric@gmail.com>> wrote:
>
>
> Le 23/04/2013 11:16, Ryan Sleevi a écrit :
>>
>>
>> On Apr 23, 2013 12:37 AM, "Israel Hilerio" <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
>> >
>> > WG,
>> >
>> > In the IE team we believe that defining overload methods that use ArrayBuffer for the operations below make it easier for developers to use the APIs without having to be constantly creating new objects or casting. From our perspective there is no internal difference on how ArrayBuffer or ArrayBufferViews are handled internally.
>> >
>> > In addition, the table below contains some proposed new methods to process Streams. This would optimized the memory footprint of the operations.  The expectations is that for each of the Stream methods we would have a stream result from which developers could read information.
>> >
>> > See Attachment #1 (table1.html)
>> >
>> > We expect the following processing to take place as part of the Streams:
>> > 1. Open a stream
>> > 2. Pass the streams as input
>> > 3. Create output stream
>> > 4. Read data from input stream when available
>> > -->Input buffer sizes are defined by the UA
>> > 5. Process the data from input stream
>> > 6. Put processed data into output stream
>> > 7. Generate and send progress event
>> > 8. If the stream is not done, goto step 4.
>> > 9. Continue normal processing of data
>> >
>> > We also believe it is better to return an ArrayBuffer type for the operations below because it avoids the implicit type cast we would have to do with an ArrayBufferView.  In other words, when returning an ArrayBufferView, we methods need to cast the ArrayBufferView to a specific type (e.g. Uint8Array, Int8Array, Int16Array, Uint16Array, etc.).  Unfortunately, there is not enough information provided by the API usage to guess correctly at the correct view type.
>> >
>> > In addition, to avoid the potential casting of ArrayBuffer into ArrayBufferView we believe it would be useful to create a new type called AlgorithmInputData:
>> > -->typedef (ArrayBuffer or ArrayBufferView) AlgorithmInputData;
>> >
>> > This would allow the various input dictionaries to be able to support input variables with either ArrayBufferView or ArrayBuffer.
>> >
>> > Our proposal is to change the following Algorithm result to ArrayBuffers (empty fields are unaffected).
>> >
>> > See attachment #2 (table2.html)
>> >
>> > Thanks,
>> >
>> > Israel
>>
>> Thanks for the feedback, Israel.
>>
>> Can you provide more explanation about these proposed changes.
>>
>> This seems inconsistent with the work going on in WebApps to *unify* the API designs on ArrayBufferViews (e.g. XHR and FileAPI as two examples). This also conflicts with the feedback received from both Mozilla and Google when early versions of the API did support such overloads that such overloads were a bad design. Given the work going on in other WGs to avoid such overloads, it would be helpful to better understand the concerns presented here, especially given that ArrauBufferViews require no copying of data to create.
>
>
> Unless there are some changes that will happen in the future that I am not aware of, WebSockets are using ArrayBuffers.
>
>
>> The WG also specifically agreed that Streams would NOT be a v.1 deliverable. While useful, the lack of adequate progress of the Streams API in the past year is a clear sign that it lacks the standards maturity to couple to this spec. The proposed Streams API in WebApps already suffers concerns as it relates to performance and the "pull" nature of data. Our past call agreed specifically to drop any such deliverable from v.1 of the API - in order to make continued progress.
>>
>> The choice of ArrayBufferView for the result, rather than ArrayBuffer, may be viable. Alternatively, DataView seems equally viable, while maintaining the ArrayBufferView semantics, which seems friendlier for callers.
>
>
> Right now I don't have a preference between ArrayBuffer and ArrayBufferView but as far as streaming is concerned (if applicable now), then most likely DataViews will be used (because of the endianness aspect of Typed Arrays), DataViews are more friendly but some might want to use [] (Typed Arrays) to read the buffers, and if general ArrayBufferViews are used then to instanciate a DataView you must do it with ArrayBufferView.buffer's ArrayBuffer, then maybe ArrayBuffer covers more cases (not withstanding the feedback of Google and Mozilla that you mention above and that we don't know).
>

Aymeric,

This feedback was sent to the list and is in the archives and minutes. It was nearly a year ago that these conversations happened.

Ryan,

Probably you are refering to http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0072.html, but sorry I don't understand quite well the arguments, I have never seen anybody work with ArrayBuffers as such, everybody creates an ArrayBufferView (not talking about streaming here, just in general), so it's equivalent somewhere to return an ArrayBuffer or ArrayBufferView, in both cases you must convert to something (but you say that for ArrayBufferView you do not need to copy anything, so you don't instantiate the underlying buffer? You will have too since that's the first thing that you will call to create your adapted view).

And why do you say "may be viable", if the decision is already taken that ArrayBufferView are better? I have already asked the question (structured clone discussion) but I don't find an API working with ArrayBufferViews (the convergence effort for File or XHR does not look obvious in the specs)

Just trying to understand this, as a matter of fact, due to lack of existing examples and knowledge when I started, it appears that for some of my projects I am not using exactly correctly ArrayBufferViews and it's difficult to revert now.

Regards,



Likewise the discussions of Blobs vs ArrayBufferViews, in which ABV was chosen over Blob, even though Blob could arguably streamline things (by virtue of avoiding a BlobReader/FileReader roundtrip).

>> Cheers,
>> Ryan
>
>
> --
> jCore
> Email :  avitte@jcore.fr<mailto:avitte@jcore.fr>
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr<http://www.jcore.fr>
> Webble : www.webble.it<http://www.webble.it>
> Extract Widget Mobile : www.extractwidget.com<http://www.extractwidget.com>
> BlimpMe! : www.blimpme.com<http://www.blimpme.com>



--

jCore

Email :  avitte@jcore.fr<mailto:avitte@jcore.fr>

iAnonym : http://www.ianonym.com

node-Tor : https://www.github.com/Ayms/node-Tor

GitHub : https://www.github.com/Ayms

Web :    www.jcore.fr<http://www.jcore.fr>

Webble : www.webble.it<http://www.webble.it>

Extract Widget Mobile : www.extractwidget.com<http://www.extractwidget.com>

BlimpMe! : www.blimpme.com<http://www.blimpme.com>