Re: [IndexedDB] A versionchangeblocked event
On Fri, Sep 24, 2010 at 1:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? I guess it isn't strictly needed, pages can always install a timeout and cancel that timeout when the success event fires. But I think it might be worth having still since it's generally hard to get people do to proper error handling, and so it's extra important to make it easy for people to do so. Hmmm. Yeah, I guess I can buy that. J
Re: [IndexedDB] A versionchangeblocked event
Btw, I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10765 but emails from the bug tracker are currently broken. On Mon, Sep 27, 2010 at 11:29 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Sep 24, 2010 at 1:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? I guess it isn't strictly needed, pages can always install a timeout and cancel that timeout when the success event fires. But I think it might be worth having still since it's generally hard to get people do to proper error handling, and so it's extra important to make it easy for people to do so. Hmmm. Yeah, I guess I can buy that. J
Re: [IndexedDB] A versionchangeblocked event
Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? J On Thu, Sep 23, 2010 at 9:57 PM, ben turner bent.mozi...@gmail.com wrote: 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 jo...@sicking.cc wrote: On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@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
Re: [IndexedDB] A versionchangeblocked event
The strategy we decided on was to send a 'versionchange' event to every database that isn't closed first. Then we loop again and if there are any left that are not closed we fire the blocked event. Since we expect pages to call close() inside their 'versionchange' handler we shouldn't be firing the blocked event unless it's really necessary. -Ben On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? J On Thu, Sep 23, 2010 at 9:57 PM, ben turner bent.mozi...@gmail.com wrote: 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 jo...@sicking.cc wrote: On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@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
Re: [IndexedDB] A versionchangeblocked event
On Fri, Sep 24, 2010 at 3:17 AM, Jeremy Orlow jor...@chromium.org wrote: Are we really sure this is needed? I was just writing up a bug for this and started to wonder if we needed any event when there no longer is a block. I then realized that once you're unblocked the onsuccess should fire immediately, so there's no need. But wait...isn't this true of normal blocking as well? Basically either the onsuccess will fire immediately or onblocked will. So couldn't an app just assume it's blocked until it receives a onsuccess message? The worst case is that the web app blinks up some message to the user to close other windows, but it seems like that could happen even with an onblocked event being added. Am I missing something here? I guess it isn't strictly needed, pages can always install a timeout and cancel that timeout when the success event fires. But I think it might be worth having still since it's generally hard to get people do to proper error handling, and so it's extra important to make it easy for people to do so. / Jonas
Re: [IndexedDB] A versionchangeblocked event
On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@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? J
Re: [IndexedDB] A versionchangeblocked event
On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@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
Re: [IndexedDB] A versionchangeblocked event
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 jo...@sicking.cc wrote: On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 22, 2010 at 9:07 PM, ben turner bent.mozi...@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
[IndexedDB] A versionchangeblocked event
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. -Ben
