- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 6 Feb 2013 16:52:19 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: public-webcrypto@w3.org
On Tue, Feb 5, 2013 at 6:38 AM, Richard Barnes <rbarnes@bbn.com> wrote: > Ok, thanks, that does clarify things. That could be clearer in the current text. What we have now is: > > """ > When the process(ArrayBufferView data) method is called, the user agent must run the following steps: > ... > 4. If the underlying cryptographic implementation for the specified algorithm supports multi-part cryptographic operations, asynchrously process data, ... > ... > When a CryptoOperation is said to process data, the user agent must execute the following steps: > ... > 4. Queue a task to fire a simple event named onprogress at the CryptoOperation. > """ > > That reads to me as if every call to process() results in an onprogress() call. Would it make sense to add an "if" clause before the instruction to queue the simple event? Yes, thanks for pointing this out. onprogress should only be fired when progress has been made (and, conversely, as soon as progress has been made), where progress is defined as output being available. This does create a separate issue, although this is also true of other stream proposals, in that it forces 'someone' to buffer unconsumed-but-pending data. In a true Streams API (which there have been none progressing), one could imagine being able to glue a File to a CryptoOperation and avoid any unnecessary buffering between implementations. In the current setup, which is internally consistent with File, a caller must read from the File [buffer 1] then throw it at the CryptoOperation [buffer 2] for the CO to consume. If the File reads faster than the CryptoOperation consumes data, the CO's buffer will continue to grow until the entire File is an memory. Given that both File and the CO already map the entire /result/ into memory, I think this is a broader issue to revisit, but is not unique to the spec itself. > > --Richard > > > > On Feb 4, 2013, at 4:42 PM, Ryan Sleevi <sleevi@google.com> wrote: > >> On Mon, Feb 4, 2013 at 11:53 AM, Richard Barnes <rbarnes@bbn.com> wrote: >>> On question related to this issue that arose as we were implementing: >>> >>> If a 'progress' event is sent to a listener while a progressive operation is in progress, what is the expected content of the 'result' attribute? It seems like the developer might expect partial output to be available, but that might be possible in all cases. >> >> By definition, progress should *only* be fired when output is >> available. Can you provide a more concrete definition of the problem >> you're imagining? >> >> Not all implementations can support progressive output (ex: AES-GCM or >> other AEAD decryption, which requires the full ciphertext for the tag >> validation). So in those cases, the progress event is not fired until >> the CryptoOperation is finish()'d. >> >> The same (non-progressive output) also applies to hash operations, for example. >> >>> >>> >>> >>> On Jan 31, 2013, at 2:08 PM, Ryan Sleevi <sleevi@google.com> wrote: >>> >>>> http://www.w3.org/2012/webcrypto/track/issues/18 >>>> >>>> I would like to propose that we CLOSE ISSUE-18. >>>> >>>> The current API already incorporates supports for progressive >>>> operations, such as encryption or hashing. Alternative semantics, such >>>> as those afforded by the Streams API proposal, have not progressed in >>>> their relevant working groups. Further, proposals for URI-like schemes >>>> (such as createObjectURL) have already shown to be significantly >>>> complex to implement correctly and efficiently. >>>> >>>> As such, I do not believe this is an issue for this working group to >>>> resolve, unless we're willing to hold further activity until the >>>> alternative specifications are proposed. >>>> >>> >
Received on Thursday, 7 February 2013 00:52:47 UTC