On Fri, Aug 6, 2010 at 12:37 AM, Jonas Sicking <[email protected]> wrote:
> On Thu, Aug 5, 2010 at 4:02 PM, Pablo Castro <[email protected]> > wrote: > > > > -----Original Message----- > > From: [email protected] [mailto: > [email protected]] 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
