W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Web Storage: apparent contradiction in spec

From: Michael Nordman <michaeln@google.com>
Date: Wed, 26 Aug 2009 16:55:08 -0700
Message-ID: <fa2eab050908261655u5c412c68o7b0cb6d05322a3f4@mail.gmail.com>
Ok... I overstated things ;)

What seems inevitable are vista-like prompts to allow something (or prods to
delete something) seemingly unrelated to a user's interaction with a site...
please, oh please, lets avoid making that part of the web platform.
I'm assuming that UA will have out-of-band mechanisms to 'bless' certain
sites which should not be subject to automated eviction. If push comes to
shove, the system could suggest cleaning up one of these 'blessed' sites if
inactivity for an extended period was noticed. But for the overwhelming
number of sites in a users browsing history, its a different matter.

If the storage APIs are just available for use, no questions asked....
making the storage just go away, no questions asked, is symmetrical.

Blessing involves asking questions... making it go away does too.



On Wed, Aug 26, 2009 at 4:35 PM, Peter Kasting <pkasting at google.com> wrote:

> On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman <michaeln at google.com>wrote:
>
>> A mandate from on high that says 'shall store forever and ever' will be
>> promptly ignored because its impossible to make that guarantee.
>>
>
> That's not the proposed mandate.  The proposed mandate is "thou shalt not
> discard successfully-written data without explicit user action", which seems
> implementable to me.  Note that this doesn't make claims like "the hard
> drive will not fail", and it doesn't claim that the UA is required to allow
> the app to write whatever data it wants in the first place.
>
> PK
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/0ad840d0/attachment.htm>
Received on Wednesday, 26 August 2009 16:55:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:16 UTC