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
On Thu, May 6, 2010 at 9:36 AM, Nikunj Mehta nik...@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
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
ian, it seems to me that nobody objects to adding a isPersistent optional
parameter to openDatabase{Sync}() in the WebSQLDatabases spec (default =
false). can you please add it to the spec? if isPersistent = true and the UA
doesn't support persistent storage, then i believe openDatabase{Sync}()
On Thu, Apr 29, 2010 at 11:56 AM, Michael Nordman micha...@google.com wrote:
Sounds like we agree on there being a distinction between two levels of
persistence with one being more permanent than the other. Great, provided
we have that agreement we can craft interfaces that allow callers to
On Thu, Apr 29, 2010 at 10:57 AM, Jonas Sicking jo...@sicking.cc wrote:
I think we were operating under the assumption that we're going to
avoid involving the user until neccesary. So for example letting the
site store a few MB of data without the user getting involved, and
only once enough
On 4/29/2010 1:08 PM, Tab Atkins Jr. wrote:
When you say per site do you mean per subdomain, or per domain? The
former is too permissive, the latter is too restrictive.
I believe he means per origin. At least that's what I took from our
discussion.
Cheers,
Shawn
smime.p7s
Description:
shawn, did you have a chance to give this some thought? how would mozilla
like to handle cases like the ones jeremy and robin mentioned? how would you
like to manage quotas?
thanks,
dumi
On Fri, Apr 23, 2010 at 11:08 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/23/2010 7:39 AM, Nikunj
On 4/28/2010 2:54 PM, Dumitru Daniliuc wrote:
shawn, did you have a chance to give this some thought? how would mozilla
like to handle cases like the ones jeremy and robin mentioned? how would you
like to manage quotas?
We chatted yesterday, but I haven't had a chance to get it down into
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some time. This will
likely be based on heuristics, such as haven't visited the site for an
extended period of time, though possibly keep the data a bit
This thinking resonates with what we've been thinking too (I think).
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some
On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman micha...@google.com wrote:
This thinking resonates with what we've been thinking too (I think).
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary
On Wed, Apr 28, 2010 at 4:17 PM, Eric Uhrhane er...@google.com wrote:
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some
We probably want to have different policies for different kinds of devices.
For mobile, pruning unused storage is definitely important, but for modern
desktops with 1TB drives most users probably won't ever need to free up
disk space unless they're hit with some kind of denial-of-service attack,
On Wed, Apr 28, 2010 at 4:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman micha...@google.com wrote:
We have in mind that the incentives for developers to not always utilize the
most permanent storage option are...
1) Non-permanent storage is
On Apr 23, 2010, at 20:08 , Shawn Wilsher wrote:
On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
Could we create an additional optional parameter for an open request with
the type of permanence required? Or is it not a good idea?
I haven't talked to anyone at Mozilla that thinks that having
On Apr 21, 2010, at 1:03 PM, Michael Nordman wrote:
On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement mi...@google.com wrote:
FWIW, the transient vs. permanent storage support is exactly why I
eagerly await an implementation of EricU's Filesystem API. Being able to
guarantee that the UA
On Fri, Apr 23, 2010 at 3:39 PM, Nikunj Mehta nik...@o-micron.com wrote:
On Apr 21, 2010, at 1:03 PM, Michael Nordman wrote:
On Wed, Apr 21, 2010 at 12:10 PM, Mike Clement mi...@google.com wrote:
FWIW, the transient vs. permanent storage support is exactly why I
eagerly await an
On Fri, Apr 23, 2010 at 7:39 AM, Nikunj Mehta nik...@o-micron.com wrote:
Could we create an additional optional parameter for an open request with
the type of permanence required? Or is it not a good idea?
I don't think we can expose the type of permanence to the user in any
sort of sane way.
On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
Could we create an additional optional parameter for an open request with the
type of permanence required? Or is it not a good idea?
I haven't talked to anyone at Mozilla that thinks that having permanent
and non-permanent-but-possibly-long-lasting
On Fri, Apr 23, 2010 at 11:08 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
Could we create an additional optional parameter for an open request with
the type of permanence required? Or is it not a good idea?
I haven't talked to anyone at Mozilla
On Thu, Apr 22, 2010 at 3:14 PM, Dumitru Daniliuc d...@chromium.org wrote:
fwiw, i agree with michael and tab that we should split all storage into
permanent/persistent and temporary/evictable/purgeable. however, i don't
think we need separate calls such as openDatabase() and
On Wed, Apr 21, 2010 at 7:58 AM, Robin Berjon ro...@berjon.com wrote:
On Tue, 20 Apr 2010 14:37:33 -0700 Michael Nordman micha...@google.com
wrote:
I think ericu is baking in a distinction in between 'permanent' and
'temporary' in the FileSystem API he's working on. Some harmony across all
On Tue, Apr 20, 2010 at 7:17 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/20/2010 4:11 AM, Mark Seaborn wrote:
1) It doesn't allow a web app to ask for a storage allocation up front,
before it starts to consume the storage.
Why does that matter?
It doesn't support the use cases that
On Tue, Apr 13, 2010 at 4:53 PM, João Eiras jo...@opera.com wrote:
On Tue, 13 Apr 2010 12:09:14 +0200, Mark Seaborn mseab...@chromium.org
wrote:
Is there any plan for involving the user in storage allocation decisions
for
IndexedDB? [1]
For comparison, the WebStorage API [2] doesn't have
On 4/20/2010 4:11 AM, Mark Seaborn wrote:
1) It doesn't allow a web app to ask for a storage allocation up front,
before it starts to consume the storage.
Why does that matter?
2) In Opera, the quota can only be increased in multiples of about 15, so it
takes three prompts to get up into the
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.
Anyone wanting to debate whether or not the UA should be free to clean up
persistent storage without asking the user should
On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta nik...@o-micron.com wrote:
As I see it, there's no such thing as permanent storage for Web browser
managed data. Even if a site expresses preferences that it would like to
keep its data resident for a long time, there cannot be a guarantee for
the
On 4/19/2010 10:08 PM, Jeremy Orlow wrote:
On Tue, Apr 13, 2010 at 3:09 AM, Mark Seabornmseab...@chromium.org wrote:
2) It is too permissive because it enforces no limit on the amount of
space a web app can use: A web app from example.com can create an
unlimited number of puppet
On Tue, Apr 20, 2010 at 5:59 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Apr 20, 2010 at 5:42 PM, Nikunj Mehta nik...@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 sdwi...@mozilla.comwrote:
On 4/20/2010 3:19 PM,
On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta nik...@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
On 4/13/2010 8:53 AM, João Eiras wrote:
Not really. The user agent can ask for quota from the user when the
limit is being hit without the webpage even having to worry about it.
Opera 10.50 does that.
I agree with this, and do see the benefit of adding more to the spec.
Cheers,
Shawn
On Mon, Apr 19, 2010 at 9:13 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/13/2010 8:53 AM, João Eiras wrote:
Not really. The user agent can ask for quota from the user when the limit
is being hit without the webpage even having to worry about it. Opera 10.50
does that.
I agree with
Is there any plan for involving the user in storage allocation decisions for
IndexedDB? [1]
For comparison, the WebStorage API [2] doesn't have any special support for
the user to make allocation choices. My understanding is that browsers have
a fixed storage limit per origin -- in Chromium, 5Mb
On Tue, 13 Apr 2010 12:09:14 +0200, Mark Seaborn mseab...@chromium.org
wrote:
Is there any plan for involving the user in storage allocation decisions
for
IndexedDB? [1]
For comparison, the WebStorage API [2] doesn't have any special support
for
the user to make allocation choices. My
35 matches
Mail list logo
