- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Mon, 9 Aug 2010 18:21:46 +0000
- To: Jeremy Orlow <jorlow@chromium.org>, Jonas Sicking <jonas@sicking.cc>
- CC: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow Sent: Friday, August 06, 2010 2:34 AM >> 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. This looks good to me too. I agree with still having deleteDatabase return an IDBRequest so the caller can tell when the operation is done. -pablo
Received on Monday, 9 August 2010 18:22:22 UTC