Re: [IndexedDB] Granting storage quotas

On Apr 20, 2010, at 5:25 PM, Jeremy Orlow wrote:

> On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher <sdwilsh@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 <nikunj@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.