Re: Streaming - [Re: CryptoOperation and its life cycle]

OK, but I suppose you will agree that :

var h1 = window.crypto.digest("SHA1");
var h2 = window.crypto.digest("SHA1");
h1.process(stream1);
h2.process(stream1);
h2.process(stream2);
h1.finish();
h2.finish();

Can not be a streaming solution.

See previous email for hash, but the same can apply for ciphering (see https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/aes.c lines 114-123 or https://github.com/Ayms/node-Tor/blob/master/lib/node-tor.js#l629-650 ), how can we get the intermediate results ?

Maybe a solution could be to reuse the crypto operation after finish (and then add something like a destroy method to CryptoOperation)


Le 13/12/2012 23:42, Ryan Sleevi a écrit :
> The API is always asynchronous. As such, .process() always returns
> void, because it must NEVER return a response within the same turn of
> the event loop (
> http://www.whatwg.org/specs/web-apps/current-work/#event-loops ).
>
> Instead, .process() causes a task to be enqueued to the event loop to
> run asynchronously.
>
> Again, there is no requirement that the underlying implementation
> support multi-part operations. It MAY decide to perform no
> cryptographic operations until the task posted by .finish() has been
> posted - indeed, if the underlying implementation does not support
> multi-part, that is the only thing it can do (that, or not support the
> algorithm)
>
> Further, if you were to say, .process(stream1), where Stream1 was an
> ArrayBufferView that contained 20 "blocks" of data for the underlying
> algorithm, it's entirely valid for the UA to process the first 10
> blocks, fire a progress event, **run the event loop**, and then
> process another 10 blocks, and fire another progress event. That is,
> two progress events - for a single ArrayBufferView.
>
> (If you're wondering why a UA would do that, we'll say cooperative
> multi-threading model where it does want to allocate more than N
> timeslices to processing data, hence only 10 blocks at a time).
>
> Alternatively, it could fire a single progress event with all 20 blocks
>
> Or it could fire no progress events until .finish() was called, fire a
> single progress event with all of the accumulated data, and then fire
> oncomplete.
>
> To put it differently, there is absolutely no 1:1 mapping between
> .process() and onprogress. .process() adds data, onprogress informs
> you when data is available - and it's up to the user agent to decide
> how to best optimize that for its underlying implementation. The only
> guarantee is that as data becomes available, progress events should be
> fired, and eventually, oncomplete will be.
>

-- 
jCore
Email :  avitte@jcore.fr
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Received on Friday, 14 December 2012 11:27:53 UTC