- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Tue, 25 Aug 2009 16:36:34 -0700
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.htm>
Received on Tuesday, 25 August 2009 16:36:34 UTC