Re: crypto-ISSUE-22: Should CryptoOperations be clonable [Web Cryptography API]

On Mon, Aug 20, 2012 at 7:19 AM, Web Cryptography Working Group Issue
Tracker <> wrote:
> crypto-ISSUE-22: Should CryptoOperations be clonable [Web Cryptography API]
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
> Some members have expressed a desire to have CryptoOperation objects be clone-able, so that the same operation may be re-used for multiple data streams, without affecting the state of the original object.
> var a = /* create a CryptoOperation */;
> var b = a.clone();  // Creates a new, independent CryptoOperation
> The outstanding questions are:
> 1) Is there consensus to support a clone() method?
> 2) If so, what are the use cases for such a method?
> 3) Is clone() a synchronous or asynchronous operation?
> 4) What are the expected differences between clone() and creating a new object with the same parameters and key(s)?
> 5) Is this clone() method part of the structured clone algorithm, or is it independent?
> 6) If an object is cloned, are the callbacks cloned or reset?
> 7) In what states is it valid to clone an object?

I'm not really sure it makes sense for CryptoOperation to be clonable.
The use cases for it are not really clear to me (hence #2 there), so
it would be good to understand.

I would expect that this would be an area for implementations to tune
accordingly, much like they do other potentially intensive uses of
resources (eg: WebGL), where they can re-use or share contexts between
multiple distinct operations, as long as their states have
transitioned accordingly.

It seems like exposing a clone() is inviting the application to manage
resources itself, which both adds to complexity and detracts from
end-user usability.

Received on Monday, 20 August 2012 14:35:41 UTC