On Apr 20, 2010, at 5:25 PM, Jeremy Orlow wrote: > On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher <sdwi...@mozilla.com> wrote: > On 4/20/2010 3:19 PM, Jeremy Orlow wrote: > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > I think a smart browser would include "am I offline" in it's heuristic for > granting storage space. > > Granting storage space is only part of the problem. > > Extrapolating from what you said, I guess I could see us keeping track of > which origins have ever been accessed offline and making sure that data is > never deleted without consulting the user. > > But, that doesn't solve this use case: something tike TiddlyWiki which lives > totally on your system and is not supposed to be synced to the cloud. The > problem is that if you used this on your desktop, which is never offline, > then the browser would not know it's precious. > > We could use the existence of an appCache manifest as a hint. I guess that > might be good enough. But then we still have the malware problem. > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 > and > the various other threads it spawned first and only re-start things if they > have new information to add. > I read it, but I don't see a consensus formed before it died off. Am I > missing something? > > It was kind of difficult to track. The basic consensus was that persistent > data can and should not be deleted without explicit user approval. > > > > On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta <nik...@o-micron.com> wrote: > > On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: > >> This way of thinking is incompatible with offline web apps. If I'm offline >> and I "send" and email, it needs to stay queued up to send until I'm >> reconnected to the internet. > > I think the problem is that data loss could occur regardless of "guarantees". > > Sure, and that came up in the original giant "thread". Even if something's > in the cloud, it could be lost. So what it really comes down to is best > effort. > > Here are the classes of storage I hear you asking for: > > 1. temporary (no likelihood of data being being stored after session ends) > > I don't think this type is very interesting. The only use case is when you > have so much data that the UA might need to spill to disk. And if you're > doing that, I'd imagine you'd want to use one of the other storage types > anyway.
This is very useful when doing B-tree manipulation such as joins and queries. One could argue that there is no value to doing in memory operations using a native B-tree implementation, but I don't buy that. I have seen many uses of this with Berkeley DB. Net net, if we are going to define durability modes, then this one is important. > > 2. evictable (no limit per site, except global limits, eviction candidates > chosen arbitrarily, including while application is running) > 3. non-evictable (no eviction, but data loss possible, limited by user) > > These 2 are what we're talking about.
