<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 25, 2009, at 3:51 PM, Jeremy Orlow wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<div class="im">On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow<<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br><br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Extensions are an example of an application that is less cloud-based.<br>
It would be unfortunate and weird for extension developers to have to<br>
worry about their storage getting tossed because the UA is running out<br>
of disk space.</blockquote><div><br></div><div>Extensions are pretty far out of scope of the spec (at least for now), right?  (Within Chrome, we can of course special case this.)</div></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div>On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke <span dir="ltr"><<a href="mailto:snej@google.com">snej@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div style="word-wrap: break-word; ">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 <i>other</i> 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.<div class="im">

<div><br></div><div>For example, Linus wrote:</div><div><blockquote type="cite">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.</blockquote>

<br></div></div><div>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.</div>

</div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div>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.  </div><div><br></div><div>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?</div><div><br><blockquote type="cite"><div class="gmail_quote"><div><div><br></div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">

<div style="word-wrap: break-word; "><div></div><div>Similar analogies — </div><div>• If the SD card in my Wii fills up, should the system automatically start deleting saved games?</div><div>• 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?</div>

<div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.)</div></div></div></blockquote><div><br></div>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. </div><div><br><blockquote type="cite"><div class="gmail_quote"><div>

<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div style="word-wrap: break-word; "><div></div><div>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.</div>

</div></blockquote><div> </div><div>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.</div></div></div></blockquote><div><br></div>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.</div><div><br></div><div>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.  </div><div><br></div><div>The cloud is within the scope of web technologies, but web technologies should not rely on the cloud.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>

<div>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.</div></div></div></blockquote><div><br></div></div><div>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.</div><div><div>I think our positions are all pretty clear, and it's coming down to this differing philosophy.  </div><div><br></div></div><div>But my position is:</div><div>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.</div><div>2) Developers should not be *forced* into using the cloud when it is not within the scope of what they're trying to develop.</div><div><br></div><div>~Brady</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>

<div><br></div><div>J</div></div></div>
</blockquote></div><br></body></html>