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

[whatwg] Proposal for local-storage file management

From: Jens Alfke <snej@google.com>
Date: Wed, 2 Sep 2009 10:46:25 -0700
Message-ID: <783AF4F5-A117-46A6-AFF6-FF340D2A16C3@google.com>

On Sep 1, 2009, at 6:35 PM, Ian Hickson wrote:

> Right now this can be done by the site directly.

You mean a download link I can click? Sure, but then the site has no  
ability to access that data later unless I explicitly locate the file  
and upload it. That's not the same thing as a storage area it can  
access.

In case it wasn't clear: In my example, the thing you're saving isn't  
a document file (like an SVG or PDF or whatever) but the actual local  
storage database for the site. Once that's been created, the site can  
continue to use it.

> Also, we'd have to keep providing persistent storage without user  
> input,
> so that the site can store preferences or the like without prompting  
> the
> user (just like cookies today).

Yes, I think it's unavoidable that there be two tiers of local  
storage, a small one that doesn't require permission and is equivalent  
to a cookie, and a larger one that does need permission. That's what a  
lot of the discussion here has been about.

>> I go through my Web Documents folder, see the old
>> "SooperAnimator.com Data" file, and trash it to save disk space.
> You can do that today with cookies, which local storage is supposed  
> to be
> exposed as in the UI. Do users ever look through their old cookies?

You can't store 50MB of data in a cookie. I'm talking about the entire  
local storage of a site here, not a 40-byte session ID or something.

?Jens
Received on Wednesday, 2 September 2009 10:46:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC