- From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
- Date: Tue, 4 Sep 2012 09:05:11 +0000
- To: Wan-Teh Chang <wtc@google.com>, Ryan Sleevi <sleevi@google.com>
- CC: Arun Ranganathan <arun@mozilla.com>, David Dahl <ddahl@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
Seems like a reasonable approach. I like the idea of deriving classes from CryptoOperation such that for example processData is not present in operations where it doesn't make sense. My proposal was trying to also advocate a specific approach to the issue of generation vs. derivation, but we can discuss that under ISSUE-36. -----Original Message----- From: Wan-Teh Chang [mailto:wtc@google.com] Sent: Thursday, August 30, 2012 10:10 AM To: Ryan Sleevi Cc: Arun Ranganathan; David Dahl; Web Cryptography Working Group Subject: Re: crypto-ISSUE-37: Method naming [Web Cryptography API] On Wed, Aug 29, 2012 at 8:01 PM, Ryan Sleevi <sleevi@google.com> wrote: > > What I dislike about 3 is that it implies a class hierarchy, of which > JavaScript isn't really class-based (it's prototype). It also > introduces a number of objects into global scope. > > Maybe > > var e = window.crypto.Encryptor(...) ? Yes, I've been assuming these are under window.crypto, otherwise the name "Verifier" would be too vague. Wan-Teh
Received on Tuesday, 4 September 2012 09:06:34 UTC