Re: [IndexedDB] Granting storage quotas

On Tue, Apr 20, 2010 at 5:42 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:

>
> 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.
>

Why not?  B-trees are a great on-disk data structure, but there are better
data structures for operations completely within memory.  IndexedDB does not
yet support joins, so I don't see that applying either.


> I have seen many uses of this with Berkeley DB.
>

You're really going to have to list some examples rather than saying "trust
me, this is important".

Net net, if we are going to define durability modes, then this one is
> important.
>

I'm not yet convinced.  :-)