- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 6 Sep 2012 10:29:40 -0700
- 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 UTC