- From: ben turner <bent.mozilla@gmail.com>
- Date: Thu, 23 Sep 2010 13:57:29 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
I'm voting for 1! I'd hate to give all the other requests a property that only setVersion requests will use. -Ben On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow <jorlow@chromium.org> wrote: >> On Wed, Sep 22, 2010 at 9:07 PM, ben turner <bent.mozilla@gmail.com> wrote: >>> >>> Hi folks, >>> >>> While implementing the latest setVersion changes Jonas and I decided >>> that it would be really useful to be able to signal to the caller that >>> other web pages are open and using the database (thus preventing a >>> setVersion transaction from running). >>> >>> Consider a web page open in two windows, one minimized or otherwise >>> obscured and the other in the foreground. If the background window is >>> running a transaction then the foreground window will not be able to >>> immediately begin a setVersion transaction when it makes that request. >>> The spec currently informs the background page that it should close >>> all its databases, but it would be even more useful to inform the >>> foreground page that it is currently blocked. That way the foreground >>> page could display some kind of notification ("Hey, you! Go close your >>> other tabs if you want us to upgrade the database!") that would aid >>> the process. We are also relying on page authors to correctly call >>> close() on their databases in response to the "versionchanged" event >>> and I don't believe that they will always follow through. >>> >>> Jonas and I thought of three possibilities: >>> >>> 1. Make setVersion return a special kind of request that had an >>> "onblocked" event handler. The caller could then add a handler just as >>> they do for success and error conditions. >>> 2. Make all IDBRequests have an "onblocked" handler, but just never >>> call it in other situations. >>> 3. Fire a "versionchangeblocked" event at the database. >>> >>> What do you guys think? Any preferences? I don't really like 2, and >>> I've preemptively implemented 3, but I'm not in love with 1 or 3 >>> either. >> >> This exact thing came up when we originally talked about setVersion. I >> thought Jonas proposed and we decided on 1 (though I'm not against 3)..? >> Did this just not make it into the spec? > > I think that 1 and 2 are the best solutions and I too thought that > that was what we had decided on. I don't really see the advantage with > 3 since it means that you have to register event handlers on two > separate objects, and potentially worry about colliding with other > pieces of code doing version upgrades (though the latter problem seems > somewhat far fetched). > > IMHO 2 seems simpler but I don't really care between 1 and 2. I'll > note that there is lots of precedence in the HTML5 spec of adding > attribute handlers on objects even though they don't necessarily fire > on the given object. This was done to keep down the number of > interfaces and thus keep things simpler. > > But if people prefer 1 I'm game for that too. > > / Jonas >
Received on Thursday, 23 September 2010 21:04:52 UTC