When will IndexedDb be available as persistent storage?

[pshustad]

Hi.

We are implementing an HTML5 offine-enabled application using IndexedDb as the Browser database. Currently, we are storing over 3 GB of data in different object stores (~ 1 GB in each store) . We do not really want to regard those data as temporary since our customers might be offline for a long time and need access to the system at all times. We have started getting problems with the temporary storage space getting exhausted and look forward to switch to persistent storage, using the Quota Management API.

https://developers.google.com/chrome/whitepapers/storage states that "The plan is to put all HTML5 offline storage APIs—including IndexedDB, Application Cache, Files System, and other APIs that might be specified—under the Quota Management API. You will be able to manage all storage allocation with it".

Does anyone know when this is planned to be implemented?

Regards,

  Per

[David Grogan]

AFAIK this is not planned for the near future.

Have you looked into using a chrome app that requests unlimited storage in the manifest? It might be a sufficient work around.

Regards,

  Per

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.
To post to this group, send email to chromiu...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.
 
 

[pshustad]

Yes, I have looked into the chrome app solution and see this as a possible workaround. However, it requires more sophisticated users, as described here.

Anyway, thank you very much for your swift reply.

[Shachar Zohar]

Is there an issue for this?

[Joshua Bell]

There is now. :)

http://crbug.com/340350

--

You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.
To post to this group, send email to chromiu...@chromium.org.

Visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/.

[subhran...@globallogic.com]

Hi All, 

Storage Newbie here... Does the data in indexedDB gets wiped out when user -

1. closes the browser tab. ?

2. closes the browser ?

3. shuts down the PC ?

Regards,

Subhranshu Das

[PhistucK]

I think it is wiped out when the disk space is relatively low.

I believe a persistent storage will never be wiped out.

☆PhistucK

Visit this group at https://groups.google.com/a/chromium.org/group/chromium-html5/.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Subhranshu Das]

Thanks for the reply.

Kust to clarify my understanding, so in a hypothetical scenario where the disk space is nearly huge...as long as the USER doesn't explicitly wipe off data from the browser the data in indexedDB is going to live ? even in the 3 scenarios i mentioned - 

1. closes the browser tab. ?

2. closes the browser ?

3. shuts down the PC ?

And is the behavior cross browser (IE11+, Chrome, FF, Safari, mobile browsers as well)

Regards,

Subhranshu

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html5+unsubscribe@chromium.org.

[PhistucK]

I only know about Chrome, but it makes sense to me that all of the browsers behave more or less the same.

Nothing is evacuated when the tab, browser or system is shut down. The whole point of having a storage mechanism is that it will persist (at least a bit).

(Even those old cookies can persist system shutdowns)

☆PhistucK

[Joshua Bell]

There are some complications.

• In Incognito mode the data is only retained until the end of the session (e.g. incognito window is closed)
  
• There are options in settings (Privacy and security > Content settings > Cookies) that allow sites to be marked "Clear on exit', in which case the data for those sites is cleared when the browser is closed.

Most browsers have some sort of "private browsing" concept like Incognito, and presumably behave similarly. I'm unsure if they have "clear on exit" options.

Otherwise, just to be explicit about Chrome's behavior:

• By default, storage is "best effort"; a site's data is retained until heuristics kick in. Currently in Chrome, the heuristics are to use at most a certain amount across all sites, and to retain a small amount of disk space free. When those "storage pressure" conditions kick in, site data is evicted on an LRU basis.
• Sites can request the "persistent" permission. If granted, the site is immune to storage pressure-based. In Chrome, the permission is granted based on heuristics around site engagement, rather than explicitly prompting the user.

Additionally, regardless of permissions, if the user manually clears browsing data then the data is wiped.

Only Firefox also implements the persistent permission so far. All browsers have different heuristics about retention and eviction, but as PhistucK describes they have broadly similar behavior about retaining data across sessions by default.

[PhistucK]

Does the "persistent" permission apply to IndexedDB? I seem to recall it did not apply to it (I might be confusing storage mechanisms here).

What does it apply to?

☆PhistucK

[Joshua Bell]

Naming is unfortunately messy here.

Circa 2010 or so there was an earlier proposal for each origin to have two storage namespaces, "PERSISTENT" and "TEMPORARY". The only APIs that exposed this split were the Chrome-only webkitRequestFileSystem API and webkitStorageInfo/navigator.webkitXXXStorage APIs. Other APIs (WebSQL, Indexed DB, Cache API, ...) implicitly use the "TEMPORARY" namespace.

That was abandoned, and apart from those legacy, Chrome-only API surfaces and plumbing in the code, what was called "TEMPORARY" is now just referred to as the origin's default storage bucket in spec language, and behaves as I described earlier in the thread. By default the persistence is "best effort" but a permission can be granted elevating it to "persistent".

It's best to ignore the legacy "PERSISTENT" if you can, otherwise think of it as some strange parallel universe of storage.

[PhistucK]

Does that mean that the "persistent" permission applies to all of the storage mechanisms in a permitted origin (WebSQL, Indexed DB, Cache API, local storage, cookies... Am I missing more mechanisms?) except the file system API?

☆PhistucK

[Joshua Bell]

The "persistent" permission applies to all of those *and* the file system API's "TEMPORARY" namespace too. 

A quick attempt at a diagram here:

https://docs.google.com/drawings/d/1K1fn6FawDITsiChAZ7pcVolee9EMNHo5xYV3prt4pmY/edit?usp=sharing

Re: more mechanisms: Service Worker storage (registrations, script cache, etc) is a storage API. Background Fetch storage is being treated this way too for the purposes of quota. Local Storage is handled differently for the purposes of quota, but has the same persistence guarantees as the other types.

[PhistucK]

Thank you fro the clarification!

☆PhistucK