- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Wed, 11 Sep 2013 14:28:40 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: Richard Barnes <rbarnes@bbn.com>, Jim Schaad <ietf@augustcellars.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <523061F8.8040104@gmail.com>
If I read correctly your different answers, the issues are about
handling events, progress with promises and even EventTarget.
What I meant is :
var ws=new WebSocket(xxx);
ws.onmessage=function(evt) {
//calculate the hash of the stream using evt.data
//encrypt the stream using evt.data
};
is not related to the API itself handling events, but to the API
handling progressively the data made available by the events of another
API, so it's somewhere different except that the promises are
re-asyncing what is already async (onmessage events here).
This seems to be a very simple and basic use case but not feasible
currently.
Here we are not taking about what will exist in the future but about
already existing use cases, so the API should cover them.
I am not aware of a systematic "natural termination state (EOF)" for
streams, most of the time the only one being able to decide the end of a
stream is the one processing the data.
We don't have to rush but I don't understand what you are expecting from
Streams and how you intend to use them for progressive operations (example?)
Regards,
Aymeric
Le 10/09/2013 19:41, Ryan Sleevi a écrit :
>
>
>
> On Tue, Sep 10, 2013 at 1:15 AM, Aymeric Vitte <vitteaymeric@gmail.com
> <mailto:vitteaymeric@gmail.com>> wrote:
>
> The problem is that the WebCrypto API as it is now without
> progressive operations can look of very little use to any reader.
>
> While thinking about Streams/File delta data, I was wondering: am
> I allowed with WebCrypto to do
> crypto.sublte.encrypt(very_enormous_buffer)?
>
>
> Yes. The same way you are allowed to do a File operation or a Canvas
> operation with very_enormous_buffer.
>
>
> I know three(four) Streams proposals, see the links in [1].
>
> The first one (Mozilla) does mix promises and eventtarget for
> reasons I don't get, the second one (Microsoft) is quasi a
> copy/paste of the File API (with things like StreamBuilder that
> are probably outdated), the third (Google?) is not detailed
> enough, the fourth (Aymeric) is a big simplification of the first
> + the second + the third with pending points related to progress
> promises and data consumption for results that don't need to be
> incremented.
>
> Indeed Arun did promptly remove recently the wrong partial blob
> data definition in the File API, which anyway was not implemented
> by browsers, but the same should be corrected in XHR too taking
> care of backward compatibility.
>
> What I find wrong in most of the proposals is the fact that the
> Stream interface is supposed to fire events by itself or to get
> them from we don't know where by some magic, this is never the
> case in real life and for existing implementations/APIs, that's
> what I have tried to highlight in the above link (and previous
> answers to this thread [2], and code example [3] which would just
> work fine if delta data were available), streams are read from
> events from other interfaces and it's already async.
>
>
> Using the event loop like this actually carries with it some
> non-trivial perf-penalty that ideally could be avoided.
>
> Still, the merits of the stream proposals are, I think, better left
> for WebApps/Script-coord.
>
>
> So probably you will say: please continue posting your comments to
> WebApps but coming back to WebCrypto, even when a Stream interface
> will (hopefully) be final, there will not be enough magic in the
> interface to guess by itself if process or finish should be
> called, so WebCrypto will still need to handle process and finish,
> so you will need to reintroduce something like a CryptoOperation,
> then why removing it?
>
>
> I fail to see what you mean here.
>
> Any Stream interface will have a natural termination state (EOF). Upon
> EOF, you can (implicitly) finalize the message. That is, imagine
> Crypto as a transformation, much the same as compression. It takes
> (one or more) input streams and yields (one or more) output streams.
> When the inputs are finished, the Crypto can then finalize the outputs.
>
> Regardless, however, it's important that we NOT try to actively
> include something we think will be useful in the future. Rather, we
> should make sure we neither close ourselves off to potential designs
> NOR do we try to rush something out and ignore the discussions happening.
>
>
> Regards,
>
> Aymeric
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0353.html
> [3]
> http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0003.html
>
> Le 10/09/2013 00:12, Ryan Sleevi a écrit :
>> Richard, Aymeric,
>>
>> The point is, as was discussed during the F2F, that progressive
>> operations are not done in this iteration.
>>
>> 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
>> <mailto: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
>> <mailto: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 <mailto: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
>> >
>> >
>> >
>>
>>
>
> --
> jCore
> Email :avitte@jcore.fr <mailto:avitte@jcore.fr>
> Peersm :http://www.peersm.com
> 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>
> Extract Widget Mobile :www.extractwidget.com <http://www.extractwidget.com>
> BlimpMe! :www.blimpme.com <http://www.blimpme.com>
>
>
--
jCore
Email : avitte@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web : www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Wednesday, 11 September 2013 12:29:11 UTC