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

I believe we're in sync here.

With regards to ArrayBuffer, I don't have a strong problem for keeping it as is right now.  I'm sure we'll get developer feedback when implementations are available.

Let me talk to my guys internally to better understand how Streams can seamlessly integrate into the existing spec and get back to you.

Thanks,

Israel

On Thursday, May 2, 2013 11:06 AM, Ryan Sleevi wrote:
> 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 20:39:35 UTC