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 <sysbot+tracker@w3.org> wrote:
> crypto-ISSUE-22: Should CryptoOperations be clonable [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/22
>
> 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