W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Granting storage quotas

From: Dumitru Daniliuc <dumi@chromium.org>
Date: Thu, 6 May 2010 13:50:47 -0700
Message-ID: <u2je753f47f1005061350je3b93875u72e992bda7e306bb@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Nikunj Mehta <nikunj@o-micron.com>, Ian Hickson <ian@hixie.ch>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Robin Berjon <robin@berjon.com>, public-webapps WG <public-webapps@w3.org>, Shawn Wilsher <sdwilsh@mozilla.com>
nikunj, i agree with what jeremy said. i think we need each storage API to
be able to specify what kind of storage it needs (and i'm trying to add an
optional flag for that to WebSQLDatabases, which is your option #1). in
addition to that, i think we need an API that would allow an app to request
persistent storage up front independent of the specific storage APIs the app
will use (your option #3?), but it doesn't look like that is going anywhere.

dumi


On Thu, May 6, 2010 at 3:30 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

> 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
>
Received on Thursday, 6 May 2010 20:51:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT