[whatwg] Web Storage: apparent contradiction in spec

[Jeremy Orlow]

On Tue, Aug 25, 2009 at 4:18 PM, Brady Eidson <beidson at apple.com> wrote:

>
> On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:
>
> On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman <aa at google.com> wrote:
>
>> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
>>
>> Extensions are an example of an application that is less cloud-based.
>> It would be unfortunate and weird for extension developers to have to
>> worry about their storage getting tossed because the UA is running out
>> of disk space.
>
>
> Extensions are pretty far out of scope of the spec (at least for now),
> right?  (Within Chrome, we can of course special case this.)
>
>
> The current spec is about "Web Applications" of all forms, including those
> that are offline, and others that hope to break from from the *required*
> chain to the cloud.
>
> Extensions based on web technology are just one form of this.
>  Widgets/gadgets are another.  Stand alone web applications are yet another.
>  Native applications that integrate HTML for their UI are another still.
>
> On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke <snej at google.com> wrote:
>
>> Interesting comments. Linus and Jeremy appear to be coming at this from a
>> pure "cloud" perspective, where any important or persistent data is kept on
>> a remote server and the browser, so local storage can be treated as merely a
>> cache. That's definitely a valid position, but from my perspective, much of
>> the impetus for having local storage is to be able to support *other* application
>> models, where important data is stored locally. If browsers are free to
>> dispose HTML5 local storage without the user's informed consent, such
>> applications become dangerously unreliable.
>> For example, Linus wrote:
>>
>> User agents need to be free to garbage collect any local state. If they
>> can't then attackers (or the merely lazy) will be able to fill up the user's
>> disk. We can't expect web sites or users to do the chore of taking out the
>> garbage.
>>
>>
>> Replace "user agent" -> "operating system" and "local state" -> "user
>> files", and you have an argument that, when the hard disk in my MacBook gets
>> too full, the OS should be free to start randomly deleting my local files to
>> make room. This would be a really bad idea.
>>
>
> Well, it's certainly different from what we're used to.  I'm not convinced
> it's wrong though.  The web has gotten by pretty well with such a model so
> far.
>
>
> But behind the scenes, developers have shoehorned their own data storage
> solutions in to place because there hasn't been a good solution in place.
>
> Why should an app that is largely about client side experience have to
> store user preferences in cookies and hope they won't be purged, or load a
> plug-in that has reliable local storage, or sync preferences over the cloud
> to a server?
>
>
>  Similar analogies —
>> • If the SD card in my Wii fills up, should the system automatically start
>> deleting saved games?
>> • If my iPhone's Flash disk gets full, should it start deleting photos?
>> What if I haven't synced those photos to my iTunes yet?
>>
>> In each of those cases, what the device actually does is warns you about
>> the lack of free space, and lets you choose what to get rid of.
>>
>
> It's worth noting that today, OSs do a pretty poor job of helping you with
> this task.  (I don't see any reason why the spec will prohibit UAs from
> creating a good UI for this, though.)
>
>
> I completely agree OSs do a pretty poor job of helping with the task.
>  Browsers might be an innovating space here.  I challenge you to come up
> with a great UI for this that shows up in a UA.  I challenge the WHATWG to
> not decide that deleting user data is okay because it's the easiest way
> out.
>
>
>
>> Local storage is different from cloud storage. The HTML5 storage API can
>> be used for both, so it shouldn't be limited to what's convenient for just
>> one of them.
>>
>
> I still don't understand what use local storage has outside of 'cloud
> storage'.  Even in the extensions use case (which I think is out of scope
> for this spec), there's no reason you can't sync user preferences and such
> to the cloud.
>
>
> Once thing I think that HTML5 has made clear is that "web technologies" are
> no longer exclusively about "web sites" that exist solely "in the cloud."
>  Widgets/gadgets, html-based extensions, offline web applications, and
> native applications that use HTML/JS/CSS to embed parts of their UI are
> *all* covered by HTML5, and I don't think requiring the cloud for any of
> them is necessary.
>
> Also - and I don't mean this to be flippant, I raise it as a serious point
> - not all web application developers are Google or Apple with access to a
> server infrastructure.  To many web developers, just "throwing data up on a
> server somewhere" is outside the constraints of their resources or their
> design.
>
> The cloud is within the scope of web technologies, but web technologies
> should not rely on the cloud.
>
> By the way, in case it's not clear, my position is not that UAs should take
> deleting user information lightly, my position is 1) this behavior should be
> left up to the UA and 2) when possible, developers should keep information
> in the cloud not local storage.
>
>
> Don't take my hyperboles too seriously - I don't *seriously* think that
> anyone is suggested browsers should be light hearted about deleting user
> data.
> I think our positions are all pretty clear, and it's coming down to this
> differing philosophy.
>
> But my position is:
> 1) If this behavior is left up to the UA, then developers who are using web
> technologies to write applications and they don't want to have to worry
> about "the cloud" for their data are out of luck, because *one* browser that
> is willing to delete data behind the scenes ruins their reliable picture of
> the technology.
> 2) Developers should not be *forced* into using the cloud when it is not
> within the scope of what they're trying to develop.
>

I still think there are non-trivial downsides to treating local storage (and
presumable database) data as "sacred", but I guess I'm convinced that it's
the correct way to go.  I hate throwing UI at problems, but it really does
make a good deal of sense in this case.  Heuristics will still be helpful in
that we can suggest what to delete to the user, but I guess the user should
always make the final decision.

Linus, are you convinced?

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/d4e84afb/attachment-0002.htm>