W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

RE: crypto-ISSUE-37: Method naming [Web Cryptography API]

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>
Message-ID: <382AD43736BB12439240773F68E90773AC9DB3@DF-M14-23.exchange.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 September 2012 09:06:35 GMT