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

On Apr 23, 2013 6:48 AM, "Aymeric Vitte" <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> 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.

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
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com