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

A few comments inline

On Wed, May 1, 2013 at 11:26 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> 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:
>>

<snip>

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

Right. The tension here is between developer convenience and overall
(Web) API consistency. I certainly agree that there's quite a
compelling argument for convenience here - why should I have to do
"op.process(new DataView(xhr.result))", when I could just write
"op.process(xhr.result)"

At the time time, I'd rather make sure that there's consistency in
paradigms with other APIs as well.

Because of this tension, and that the whole AB vs ABV is unresolved in
the APIs in general (an issue for TAG/script-coord, I believe), I'm
trying to err on the side of caution. You can always fit an AB into an
ABV, so if we only offer an ABV, then any code written will continue
to work if we were to add an ArrayBuffer overload.

However, if we add an ArrayBuffer overload now, and then decide it's
incorrect (as it seems the File/Blob constructor API discussions
lead), well, we can never remove that overload - it's part of the
platform now.

I've certainly flagged it for review internally, but I think the
broader issue would be approaching WebApps and TAG and saying "What is
the preferred state of the art" here - since the whole point of the
TAG is to provide inputs to WGs such as ourselves and ensure the web
platform is developed somewhat consistently/coherently, rather than
just a collection of specs [as it realistically is today]

<snip>
>> >
>> > * MSE appendBuffer(ArrayBuffer)
>> >
>
> I noticed that you didn't address the use of ArrayBuffer overloads on MSE as part of your argument.

That's because I suspect that the authors of the MSE may not be
following the discussions going on in other specs / have discussed
with the TAG.

The fact that this is a fragmented area is exactly why I'm nervous
about adding it 'because some other spec' did.

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

Sure.

To be clear, I'm totally on board with exploring the Streams proposal
- I'm not at all trying to shut it down or say we're not going there.

Rather, I'm trying to highlight areas of concern with both the Streams
spec AND with the proposal for Streams for the Web Crypto API, and
asking you to further flesh out the details or how it might be
addressed.

As I mentioned, I was the (sole?) proponent for Streams early on, so
you don't need to sell me on their benefits. But the issue was and is
understanding how we can see a consistent API evolve to support them.

As a thought exercise, I'm not at all opposed to seeing a radically
different low-level API proposal that looked at Streams only, to show
how an internally-consistent Streams API would look. We could then use
that as a discussion/comparison point for the existing API to see how
to leverage streams. Alternatively, if you think you can propose a
consistent bolt-on/overload, I'm all for exploring that too.

My biggest concern remains consistency of concepts and abstractions -
I want to make sure that any integration of Streams feels like a
natural extension, and not some afterthought. The remaining comments
from my message were trying to highlight the conceptual incongruities
as points to be addressed.

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

As mentioned above, I have no problem with the overall vision
statement there, but I am curious why you don't see .finish() the same
as .close().

Perhaps I'm misunderstanding StreamBuilder, but AIUI, .close()
represents the caller's way of signalling "There is no further input
to come". In the CryptoOperation, .finish() is that signal. It's
important for CryptoOperation to have that signal, because some
operations can ONLY be completed once we know for certain that we've
accumulated all inputs. Whether this is signature/mac verification or
encryption where authentication tags are produced, some outputs can
only be computed once we know there are no more inputs. How does that
differ from StreamBuilder.close()?

Received on Thursday, 2 May 2013 18:06:03 UTC