[whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

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.

~Brady

>
> J

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