W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

[IndexedDB] Deleting/managing databases and entity stores

From: Jeremy Orlow <jorlow@google.com>
Date: Thu, 18 Feb 2010 15:41:28 +0000
Message-ID: <5dd9e5c51002180741l79131f94n690d5b2dfd1f5dfc@mail.gmail.com>
To: public-webapps WG <public-webapps@w3.org>
Some feedback/issues based on talks with web apps teams at Google.

With WebSQLDatabase, there's been some concern and headache over users being
able to easily delete individual databases without fully understanding the
consequences (and the fact that it might break apps in strange and
unpredictable ways).  It'd be nice if we could do better for IndexedDB.

Some possible ideas (mostly just brainstorming): modify the version number
or have a "tainted" bolean that says when something other than the web app
has mucked with the database (so a web app can then do an integrity check);
have a boolean for database that says "if one entity store / index is
deleted, we strongly suggest they all be deleted"; in addition to
the description string have a string for a message shown to a user when
confirming that they really do want to muck with things; suggest to UAs that
they explain the consequences of manually editing a database in any UI they
have to do so.

In the absence of any change, I think our teams intend to use the
description field to warn users, but it seems as though we can do better
than that.

Should we also allow apps to give a hint to the UA that says "this can
safely be deleted" and/or "least recently used parts of this can be deleted
safely"?  A common use case for persistent storage is as a cache.  Sometimes
this is in the context of an app that only works online and sometimes it's a
part of an offline-enabled app that builds data structures that can be
deleted at will.  It really seems as though we should make it easier for a
UA to reclaim cache space that's not being used.

Are we sure we want the spec to say "User agents may automatically delete
stored data after a period of time."  (section 4.1).  This seems to go
against the prevailing decision when we talked about this in the context of
LocalStorage.  In the absence of any information making it explicit that
information is expendable, it seems as though any deletion should be done
only when explicitly confirmed by a user.

What is the rational for not allowing enumeration of databases, entity
stores, or indexes?  One obvious use case is tools to allow you to hand-edit
the data (for example, development tools).  What is the rational against

Received on Thursday, 18 February 2010 15:42:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC