Re: [IndexedDB] Need a method to remove a database

On Fri, Aug 6, 2010 at 12:37 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 5, 2010 at 4:02 PM, Pablo Castro <Pablo.Castro@microsoft.com>
> wrote:
> >
> > -----Original Message-----
> > From: public-webapps-request@w3.org [mailto:
> public-webapps-request@w3.org] On Behalf Of Jonas Sicking
> > Sent: Thursday, August 05, 2010 2:12 PM
> >
> >>> >> I suggest we make removeDatabase (or whatever we call it) schedule a
> >>> >> database to be deleted, but doesn't actually delete it until all
> >>> >> existing connections to it are closed (though either explicit calls
> to
> >>> >> IDBDatabase.close(), or through the tab being closed).
> >>> >>
> >>> >> Any calls to IDBFactory.open with the same name will hold the
> callback
> >>> >> until the removeDatabase() operation is finished. I.e. after all
> >>> >> existing connections are closed and the database is removed.
> >>> >>
> >>> >> This is similar to how setVersion works.
> >>> >
> >>> > If we're not going to keep it simple, then we should match the
> setVersion
> >>> > semantics as much as is possible.  I.e. add the blocked event and
> stuff like
> >>> > that.
> >>>
> >>> The "blocked" event fires on the IDBDatabase object. Do we want to
> >>> require that the database is opened before it can be removed? I don't
> >>> really feel strongly either way.
> >>>
> >>> The other question is if we should fire a "versionchange" event on
> >>> other open IDBDatabases, like setVersion does. Or should we fire a
> >>> "holy hell, your database is about to get nuked!" event? The former
> >>> would keep things simpler since there is just one event to listen to.
> >>> The latter might be more correct.
> >>>
> >>> / Jonas
> >
> > I like the idea of just scheduling the database to be deleted once the
> last connection to it closes, and also preventing any new connection from
> being established once the database has been scheduled for deletion. This
> adds as little surface area as possible to the API.
> >
> > If we find that that's not a good idea for some reason, I wonder if we
> should unify the "versionchange" event and this into a single "stuff
> seriously changed" event where subscribers need to close their handles and
> let go of any assumptions they had about the database. Once they can
> re-open, they need to re-establish all their context (this is already true
> for a version change, we may as well extend it to database deletes and any
> other future big changes to the database schema, options, etc.)
>
> Here's my proposal, please poke holes in it:
>
> interface IDBFactory {
>  ...
>  IDBRequest deleteDatabase(in DOMString name);
>  ...
> };
>
> When deleteDatabase is called, the given database is scheduled for
> deletion. If any IDBDatabase objects are opened to the database fire a
> "versionchange" event on those IDBDatabase objects, with a .version
> set to null. If any calls to IDBFactory.open occur, stall those until
> after this algorithm is finished. Note that this generally won't mean
> that those open calls will fail. They'll generally will receive a
> newly created database instead.
>
> Once all existing IDBDatabase are closed (implicitly or explicitly),
> the database is removed. At this point any IDBFactory.open calls are
> fulfilled and a "success" event is fired on the returned IDBRequest.
>
> So no "blocked" event is fired as I'm not sure where to fire it. I'm
> also not sure that this is a big problem. I'm not even sure that
> returning a IDBRequest is worth it. The only value I can see is
> wanting to display to a user when a database is for sure deleted as to
> allow the user to for example safely shut down the computer without
> worrying that sensitive data is still in the database.
>

All of this sounds good to me.  I'd probably still return an IDBRequest
for consistency and so that the app can get a conformation when it's really
gone.  On success would fire with a "null" result field, I'd think.

J