Re: Rethinking KeyStorage

On Wed, Nov 7, 2012 at 10:37 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> 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.

Considering that it was merely presented within the spec as a
strawman, and without sufficient or significant discussion within the
WG, I do not feel that it should suddenly have a higher bar for
removal than it did for addition.

If anything, your continued insistence that it cannot be removed only
serves to discourage people from contributing to the group, since it
runs the risk that unless the idea is perfect on the first attempt, it
will be impossible to remove.

We should simply remove it from the spec, acknowledge it as an ongoing
issue, and continue. If we cannot resolve the issue within the
schedule afforded to this group, then we can take appropriate action -
either blocking progress (and implementation) of the spec until a
suitable alternative can be found, or accepting (as I propose) that
features that cannot be universally agreed upon or implemented are not
blocking for Candidate Recommendation.

While I came to neither praise nor bury web storage, the issues were
presented during the face to face, were re-iterated and amplified
within the WebApps WG. A simple survey of appropriate literature (let
alone the many and varied discussions in WebApps)

- http://blog.mozilla.org/tglek/2012/02/22/psa-dom-local-storage-considered-harmful/
- http://webreflection.blogspot.co.uk/2012/03/whats-localstorage-about.html
- http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api/

A small selection of the issues:
- Synchronous API
- Poor / undefined locking behaviour
- Poor eventing model
- Poor performance
- Poor / no querying support

Further, given the strong overlap between pre-provisioned keys and
other forms of discovered keys, I believe it's very important that we
have a single, unified, consistent interface for accessing keys that
were not directly created by the origin.

>
>> 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.

That's not generally how these processes work. If the current idea is
a poor API (and again, it's well acknowledged and was particularly
re-iterated during TPAC in WebApps), it should be removed. If a member
of this WG feels that there are outstanding issues not addressed in
the spec, we should leave ISSUEs to indicate "more work needed here".

However, suggesting that we use a bad interface as the marker for
there being an outstanding issue is a very poor signal, and
effectively makes compatible or experimental implementations
impossible.

These are already highlighted in ISSUE-31 -
http://www.w3.org/2012/webcrypto/track/issues/31 - and were also
discussed in greater detail in the WG regarding locking, indexing,
iteration, and performance. So the issues are well-known at this
point.

>
> 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
>

And during our face to face, it was agreed to adopt the proposed
storage semantics as a way to address these concerns - which involved
a re-presentation of the issues and how the new proposal addresses
them - and with WebApps as a venue to further improve and iterate on
these semantics.

Received on Wednesday, 7 November 2012 19:17:24 UTC