W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

Re: JS code examples for ACTION 43

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 6 Sep 2012 10:29:40 -0700
Message-ID: <CACvaWvbuHMdctYwR3-5+CwYJrpRY1dE8LuycSF+dA5p99Mdthg@mail.gmail.com>
To: David Dahl <ddahl@mozilla.com>
Cc: Wan-Teh Chang <wtc@google.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Thu, Sep 6, 2012 at 10:18 AM, David Dahl <ddahl@mozilla.com> wrote:
> ----- Original Message -----
>> From: "Wan-Teh Chang" <wtc@google.com>
>> To: "Ryan Sleevi" <sleevi@google.com>
>> Cc: "David Dahl" <ddahl@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
>> Sent: Thursday, September 6, 2012 12:03:29 PM
>> Subject: Re: JS code examples for ACTION 43
>
>> > [1]
>> > http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-CryptoOperation-state-processing
>>
>> I see. It is also not clear to me whether an application can call
>> processData() or complete() before a previous processData() call has
>> asynchronously completed. The spec allows that. In fact, there is no
>> event that indicates the completion of a processData() call. The
>> |progress| event is fired only if the processData() call resulted in
>> output.
>
> I see. Do we need to specify a new event?

If we do decide not to support the "shotgun calling", then yes. As
mentioned very early on, .processData() may not ever result in output
- for example, when performing signature verification (which doesn't
happen until .complete()). Being able to shotgun repeated calls to
.processData() would be rather useful in that case.

I would suggest rather than having onProgress, we'd rename it to some
event that is suitably ambiguous as to whether data resuled.
onProcessed() perhaps?
Received on Thursday, 6 September 2012 17:30:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 17:30:17 GMT