On Mon, Aug 9, 2010 at 11:21 AM, Pablo Castro <[email protected]> wrote: > > From: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Orlow > Sent: Friday, August 06, 2010 2:34 AM > >>> 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. > > 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.
I did this. The only change was that I did fire a blocked event. I don't know why I thought that there wasn't anything to fire it on, since we do have a request which works great. / Jonas
