- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 7 Nov 2012 18:37:32 +0000
- To: Ryan Sleevi <sleevi@google.com>
- CC: David Dahl <ddahl@mozilla.com>, public-webcrypto <public-webcrypto@w3.org>, Arun Ranganathan <arun@mozilla.com>, Harry Halpin <hhalpin@w3.org>
On Nov 7, 2012, at 10:24 AM, Ryan Sleevi wrote: >> I'm fine for KeyStorage to be removed on these grounds IF there is a better alternative that maintains functionality. > > The onus when removing features that are demonstrably bad (see above) If you want to remove KeyStorage just because it is "bad", you need to present the technical argument here, and then I would be happy to help make a counter-proposal that addresses those points. Just stating that it's bad (or referring off to long discussions on a different albeit similar mechanism) and only offering a less functional alternative isn't going to work if you're trying to get my agreement. > should not be that a counter-proposal be provided. It should be > removed. If there is a proposal that can address the needs and be > agreed upon within the work group as something to incorporate (and > that will be implemented - which is very much a criteria for this API > as spelled out in the charter), then we can revisit. > > However, bad features should be removed. Not kept simply because no > one has proposed something better. Is it the functionality that you think is bad, or just the API design ? Previously you said it was the design ... Badly designed features should be replaced with better designed alternatives. Or, indeed, if better designed alternatives cannot be found, they should be removed. But you should not just skip the search for alternatives and go straight to removal. Nevertheless, you need the agreement of the group and I'm suggesting that it'll be much easier to get that if you address the design issues without removing functionality. …Mark
Received on Wednesday, 7 November 2012 18:38:00 UTC