Re: [IndexedDB] Granting storage quotas

On Thu, May 6, 2010 at 9:36 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:

> Dumi,
>
> I am not sure what the API expectations are for different levels of
> durability of storage APIs. Is it:
>
> 1. Options passed to individual APIs selecting durability level
> 2. Separate API calls for different durability level
> 3. Allocations occurring through markup requiring user actions which acts
> as ambient durability level for a site.
>
> I surely would like to avoid 1 and 2. I felt like the discussion (based on
> your proposal) was leaning towards 3. However, I can't read this email in
> that way.
>
> Thanks for clarifying for my sake.
>

I don't think you've accurately characterized the situation.


1 vs. 2 has been bike-shedding so far.  In other words, I don't think there
have been any super compelling arguments for or against them, but I think 1
has had a bit more support.  Either 1 or 2 is required in order for a single
origin to have multiple levels of durability.

For example, I have 14GB of email in my GMail account.  I'd like to have
a guarantee that I have at least the last 7 days of email + any drafts +
emails in my outbox.  I'd also like it to cache all the rest, but if my hard
drive fills up, I'm happy for it to drop the extra.

Another example: I have a photo sharing site.  I upload a bunch of photos
while offline that I'd like it to upload once I get back online.  I also
have several gigs of data cached to make the photo browsing experience
better, but I'm fine with it being deleted.

These types of scenarios become even more compelling when we're talking
about mobile devices and net-books.  I know it's been argued that these
devices keep getting more storage, so we won't need to worry about it soon,
but I'd argue that storage usage keeps increasing as well.


3 is a separate issue and is related to HOW we grant permissions.  I think
several of us at Google are in favor of something like this, but I haven't
seen anyone else express interest so we're going to continue on without the
new piece of markup for now, but if there was support for it, I think we'd
be happy to go that route.

J