W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: IndexedDB: API for enumerating databases within an origin

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 21 Sep 2011 14:26:45 -0700
Message-ID: <CA+c2ei-JVt1g6DendEpqfrKJNEu4aX8RrxkHk5g7cU+gST=97Q@mail.gmail.com>
To: Joshua Bell <jsbell@chromium.org>
Cc: public-webapps@w3.org
On Wed, Sep 21, 2011 at 10:18 AM, Joshua Bell <jsbell@chromium.org> wrote:
> We've received feedback from early users of Chrome's implementation of
> IndexedDB requesting the ability to enumerate databases exist within an
> origin. We'd like the propose the following API addition to the IndexedDB
> API.
> TL;DR version:
> We add IDBFactory.getDatabaseNames() which asynchronously delivers a
> DOMStringList with database names from the current origin. We believe it is
> necessary to model this as an async operation because the first access to
> the backing store containing this information for each origin may be a
> relatively slow operation, and blocking the calling thread is undesirable.
> Spec amendments version:
> interface IDBFactory (sec 3.2.3) is extended with:
>     IDBRequest getDatabaseNames ();
> When invoked, this method MUST create a request and return it. The created
> request has no source. The method then asynchronously runs the steps for
> enumerating databases within an origin. Let origin be the origin of the
> IDBEnvironment used to access this IDBFactory.
> If an error is returned from the steps above, the implementation must set
> the errorCode of the request to the code of the error returned and fire a
> error event at the request.
> If the steps above are successful, the implementation must set the result of
> the request to the DOMStringList created by the steps above and fire a
> success event at the request.
> interface IDBFactorySync (sec 3.3.1) is extended with:
>     DOMStringList getDatabaseNames ();
> When invoked, this method synchronously runs the steps for enumerating
> databases within an origin. Let origin be the origin of the
> IDBEnvironmentSync used to access this IDBFactorySync.
> If an error is returned from the steps above, then the implementation must
> throw an IDBDatabaseException with its code and message set to appropriate
> values for the error.
> If the steps above are successful, the implementation must create a
> DOMStringList containing the database names and return it.
> And to be pedantic, the algorithm in section 4 parlance:
> The steps for enumerating databases are as follows. The algorithm in these
> steps takes one arguments - the origin making the enumeration request. It
> also optionally takes a request when this algorithm is used from an
> asynchronous API.
> 1. If these steps fail for any reason, return a error with the appropriate
> code and abort this algorithm.
> 2. Let list be a new empty DOMStringList
> 3. For each database in the origin that does not have its pending delete
> flag set, add the name of the database to list as a new DOMString
> 4. Return list

The problem with an API like this is that it's completely
untrustworthy. By the time that the success event fires, another tab
could have deleted all the existing databases and added 5 other ones.

If we're doing an API like this I would prefer to be able to provide
some guarantees. I.e., something like ensuring that if a database is
listed as existing, you are guaranteed to be able to open it if you do
so from within the success event. Likewise we might want to be able to
guarantee that the database doesn't exist if it isn't listed, so if
you create it, you'll get a upgradeneeded event with oldVersion 0.

As an aside, we might want to provide the version of the databases as
well, but we'd have to guarantee that the version doesn't change
before the page gets a chance to open it.

/ Jonas
Received on Wednesday, 21 September 2011 21:27:43 GMT

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