Re: What happened to the CryptoOperation interface?

On Sep 10, 2013, at 1:47 PM, Ryan Sleevi <sleevi@google.com> wrote:

> 
> 
> 
> On Tue, Sep 10, 2013 at 7:19 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> 
> On Sep 9, 2013, at 6:12 PM, Ryan Sleevi <sleevi@google.com> wrote:
> 
> > Richard, Aymeric,
> >
> > The point is, as was discussed during the F2F, that progressive operations are not done in this iteration.
> 
> But if that's the case, then why do you need sequence<CryptoOperationData> instead of just CryptoOperationData.
> 
> It's an entirely orthogonal issue for the sequence<> vs progressives.
> 
> The sequence<> allows you to construct framing without having to copy into a temporary intermediate buffer.
> 
> That is, imagine a message where there is 'header', 'content', and 'footer'. 'content' might be received from some other API (eg: the File API), while header and footer are application-generated metadata that is also protected. If the operations only took a single CryptoOperationData, then you would have to create a new Blob from the sequence<BlobPart> - forcing a copy (as per the File API spec) of all the data.
> 
> By taking a sequence<CryptoOperationData>, you can avoid the copy.

OK.  It seems kind of odd to optimize for that case, though, and force the extra "[]" in the single-ABV case, which I would think would be more common.  Could we abstract over this somehow?  E.g.:

typedef (ArrayBuffer or ArrayBufferView) CryptoOctets;
typedef (CryptoOctets or sequence<CryptoOctets>) CryptoOperationData;

I realize that's a little awkward, but it seems more developer-friendly.


> Note that the "pass by value" represents the observable semantics. It does not imply a logical copy of the data itself - as the CryptoOperation does not mutate the input data.
>  
> 
> Losing progressive operations makes me a little sad.  Would you mind briefly restating the reasoning for this?  I realize that the mechanics of process() are a little odd with Promises, but it seems to me that something like the following would not be nonsensical:
> 
> var op = window.crypt.subtle.encrypt(key, alg)
> op.process( dataChunk1 );
> op.process( dataChunk2 );
> op.process( dataChunkN );
> op.then( doSomethingWithCiphertext );
> 
> I'm not deeply wedded to this feature, but it does seem handy enough to keep around if it's not horrendously complex to implement.
> 
> Horrendously, heinously complex to implement and exceptionally prone to leaks and circular references. In discussing with Blink devs, there certainly was no plan to implement that portion of the spec, simply because it could not be safely implemented. (The same, arguably, applies to the previous model under Events as well, for what it's worth)

Actually, I got the same feedback today from one of our devs who's hacking on Firefox.  So I'm OK with letting this slip.

--Richard



> 
>  
> 
> --Richard
> 
> 
> 
> 
> >
> > It's clear that there's a significant problem in API consistency regarding progressive operations. You can see this in the myriad of proposals, and, as Arun notes in the latest FileAPI edits, within the FileAPI.
> >
> > Rather than include something in the spec that will either
> > a) Not be implemented [much like IDBSync]
> > b) Not be consistent
> >
> > It was removed from the spec until such a time as WebApps/Public-Script-Coord can agree on an interface. There have obviously been proposals from MSFT (re: Streams API), which was discussed *very* early on in this WG. There likewise have been similar-but-different proposals regarding ProgressPromises, such as from Mozilla.
> >
> > This still allows for a number of use cases AND has a better support story, longer term, for the API, rather than specifying known-bad interfaces (both Events and Promises had a *number* of significant issues related to progressive inputs)
> >
> >
> > On Mon, Sep 9, 2013 at 3:06 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> > I've been unplugged from this group for a while, and was likewise surprised to see this development.
> >
> > The new API appears to allow progressive input via the sequence<T> arguments.  But it's not clear to me as a naïve reader of this and the WebIDL spec how this would work.  Is the idea that you would somehow use generators / yield to create a dynamic sequence?  Maybe I don't understand generators that well, but that seems counter to the clear statements in the WebIDL spec that sequences are passed by value.
> >
> > In any case, I don't care about losing CryptoOperation, but the spec should be a lot clearer about how progressive operations are done.
> >
> > --Richard
> >
> >
> >
> > On Sep 7, 2013, at 10:27 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >
> > > This was covered on the call. The minutes from two meetings ago (if I recall correctly) should have them.
> > >
> > > The broader discussion of partial output interfaces (such as the File API) and Streams (MSE, Streams API, ProgressPromise, etc) is happening in WebApps and you can follow there to understand the broader arguments - and concerns - of such interfaces.
> > >
> > > The minutes should include the discussion as well, as they were discussed on the call. However, I haven't checked.
> > >
> > > On Sep 7, 2013 7:23 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> > > I was just going through the Editor’s draft dated 30 August 2013 and was shocked to find that there is no longer a definition of the CryptoOperation interface in the document.   Instead a sequence of CryptoOperationData objects are passed into the root call.
> > >
> > >
> > >
> > > I do however note that the excising was not complete as it is still included in the verify method description.
> > >
> > >
> > >
> > > I completely missed the reasoning behind this.  When was this discussed either on the mailing list or in a telechat so I can go back and find the justification/reasoning behind it.
> > >
> > >
> > >
> > > Jim
> > >
> > >
> > >
> >
> >
> 
>

Received on Wednesday, 11 September 2013 03:20:24 UTC