Re: CryptoOperation and its life cycle

On Tue, Dec 11, 2012 at 6:14 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> Some short questions on CryptoOperation and its life-cycle:
>
> 1. Is there a reason that the init() method needs to be explicit for CryptoOperation objects?  If there's initialization to do, couldn't the operation object just do it on the first non-trivial call it gets?

Please see the latest Editor's Draft, where this was already addressed -
https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5e8d9a3e18f/spec/Overview.html

There is some admitted under-specification, but the internal
"initialize this object" is accomplished by having the window.crypto
methods queue a task to run initialization against the newly created
object. By running initialization via a queued task (ie: after the
current task finishes processing), the caller may still attach event
listeners, enqueue data to be processed, and even enqueue completion
of the data, all within the same turn. See the example code to see how
this is done.

>
> 2. When do results get passed back?  It's not clear to me from the current spec what the state of the "result" field in the operation should be. One can imagine multiple outcomes.  For example, with digest, MAC, or signature, you would only get results in oncomplete().  But with encryption or decryption, you could get intermediate results in onprogress().  Or perhaps this is implementation-dependent?

Again, see the latest editor's draft.

onprogress follows the Progress Events model, in which the client is
informed of progress. There is always at least one onprogress event
(which may be due to the final completion of the data), and there is
always zero or one oncomplete events. At the oncomplete event firing,
all of the data is available in result.

This was raised as a point of concern by Wan-Teh back on June 20th,
but it arguably follows the model of what existing APIs (such as File
API or Streams API) do through their readAsArrayBuffer methods, and
with how XMLHttpRequest makes data available through progress events.

To be clear: .result contains the data available, and may grow to add
more data, up and until oncomplete is fired.

>
> 3. Is there a reason that complete() doesn't take data?  It seems like it would simplify things slightly if you could pass in the last chunk at that point.  (Internally, the implementation could "processData(data); complete();".)
>
> Basically, I'm wondering if we could have the following work flow for a simple case:
>
> var e = new Encryptor(/* params */);
> e.oncomplete = function(event) {
>   // Do something with event.target.results;
> }
> e.complete("Attack at dawn!");

It's a syntactic sugar argument. One would argue about "Why do we have
complete at all", with the alternative being .process("data", false /*
not complete yet */).

The more practical reason is that knowledge of the .complete() state
is often divorced from the availability of data when talking about
networking protocols. You often get a data packet (which you
.process), and then you receive a "fin" flag (or record or what have
you), in which you call .complete().

Making .complete() take optional data is an option, but it's a
syntactic sugar as well.

With the current draft, it's internally consistent that there is only
one way to add data (.process) and one way to complete data (.finish),
and there's no mixed responsibilities between them.

>
> Thanks,
> --Richard

Received on Tuesday, 11 December 2012 16:56:10 UTC