Re: [IndexedDB] Granting storage quotas

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.


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