- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Thu, 5 Aug 2010 23:02:42 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Jeremy Orlow <jorlow@chromium.org>
- CC: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
-----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.) -pablo
Received on Thursday, 5 August 2010 23:03:17 UTC