Re: [IndexedDB] Granting storage quotas

On Tue, Apr 20, 2010 at 5:59 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

> 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.
>>
>>
Oops, one thing I didn't consider is "session" as in per tab (like
SessionStorage) rather than per document.  I don't know if this is what you
originally meant (based on your arguments, I assume it's not), in which case
I'd consider this a 4th kind of storage.

Now that I think about it, I'm pretty sure the enumeration of all of these
types was done in some thread in the past.  But I believe that's it: per
document, per session/tab, caches/evictable/volatile/transient/purgable/etc,
and persistient/non-evictable/etc.