Re: [IndexedDB] blocked event could be an error
On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. I don't know by what measure it's quite early or the right time. It'd be the right time because though IDB usage is picking up, it's still relatively low. Optimally this change would have been made a few months or years ago, but now is better than later. We've passed Last Call, there are 3 shipping implementations, all of which have considered their implementation complete enough to switch from prefixed implementations to unprefixed ones. They all implement the behavior that you are proposing to change. We'd be ok with changing this, our unprefixedness notwithstanding. I think the pain it would save developers down the road would make up for the immediate pain it would cause to both vendors and developers. But that's just a judgment call, I'm relying on intuition and obviously have no data about what the future will hold. To balance the concerns of open with complicated semantics and backward-compatibility, I propose that we add two methods to IDBFactory: openOrFail and openOrBlock. Most introductory IDB tutorials and examples would steer developers towards openOrFail. The current open method would be an alias for openOrBlock. That open's documentation would be [deprecated] alias for openOrBlock should give developers some pause about using it just because it has the simplest name. At least the Amazon cloud reader uses IndexedDB. I've started receiving enough questions about IDB that I would imagine that there are more websites deployed which uses it. / Jonas
Re: [IndexedDB] blocked event could be an error
http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. The spec is still a working draft, all uses so far of IDB online are either html5 benchmarks or tutorials/examples. So, nothing of importance will be affected, Besides, this is a corner case.
Re: [IndexedDB] blocked event could be an error
On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. I don't know by what measure it's quite early or the right time. We've passed Last Call, there are 3 shipping implementations, all of which have considered their implementation complete enough to switch from prefixed implementations to unprefixed ones. They all implement the behavior that you are proposing to change. At least the Amazon cloud reader uses IndexedDB. I've started receiving enough questions about IDB that I would imagine that there are more websites deployed which uses it. / Jonas
Re: [IndexedDB] blocked event could be an error
On Wed, Sep 5, 2012 at 9:54 AM, Odin Hørthe Omdal odi...@opera.com wrote: David Grogan dgro...@chromium.org wrote: Odin wrote: Also, there's a much bigger chance of developers listening to error on the opening page, rather than blocked. +1. Replacing blocked event with an error event named BlockedError would be an improvement. I did this. Proposed patch to the spec is here: http://odinho.html5.org/IndexedDB/spec/blocked.patch If you are not super proficient reading patches but prefer to see the result, I have the file I used to produce the diff here: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas
Re: [IndexedDB] blocked event could be an error
On Fri, 27 Jul 2012 00:31:08 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 26, 2012 at 3:28 PM, João Eiras jo...@opera.com wrote:
I definitely think that we need to keep the blocked events as
non-error events since it supports the use case of opening a
connection and displaying UI to the user asking that other tabs are
closed if the blocked event fires.
That can very well be achieved by detecting the BlockedError, and
adding a retry button which calls open() again.
If you really want a open() and wait forever behavior, that should not
be the default one.
I'm not at all comfortable with changing the default behavior this
late in the process.
I really think we should change it. The behaviour we have now is very very
surprising and I don't think very sane.
If the IE implementation that's available now really is the one they're
shipping (I seem to remember they said something like that), it'll be
divergent in those parts already.
The alternatives are not that good, they are papering over a problem so
that careful developers can do the right thing, but they will probably
also write db.onversionchange = function() { db.close() } correctly. The
careless developers (of which inhabit many parts of the intertubes) will
not, and then you'd just get all those waiting requests hanging around.
If someone wants to tell me to close my other window, it's very easy to
check the error on the open request for BlockedError. Of course, if you
want it to be automatic, you'd have to try a new open with some interval,
but that shouldn't be a big problem.
I would go out on a limb and say that I think this part of IndexedDB is
probably not very much used at this point. And if there are any users,
they're hopefully already sufficently advanced to already have written a
db-close in versionchange so that they won't be relying on the blocked
system.
Well, it's a lot of hope, but I don't think this is something we should be
stuck with.
--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [IndexedDB] blocked event could be an error
On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal odi...@opera.comwrote: There are some open issues in the spec that has been there a long time. They deal with opening and deleting database. http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/** Overview.html#dfn-steps-for-**deleting-a-databasehttp://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database # 7. Wait until all objects in openDatabases are closed and all of their #transactions are finished. # #ISSUE: Should we allow blocked to be fired here too, if waiting takes #too long? # # 8. Delete db. http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/** Overview.html#dfn-steps-for-**running-a--versionchange--**transactionhttp://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction # 4. Wait until either all objects in openDatabases are closed and all of #their transactions are finished. # #ISSUE: If .close() is called immediately but a transaction associated # with the connection keeps running for a long time, should we # also fire a blocked event? # #ISSUE: If, while we're waiting here, someone calls open with a # version number higher than version, we should probably let # that upgrade run first and bail here if it was successful. To be very honest, the whole blocked and then wait-system seems very over the top for a small benefit. IMHO the harm is greater than any potential small benefit. We'd have to keep lots of requests indefinitely open. If the other page having an open database doesn't clean up and db.close() in its db.versionchange handler, most definitely the developer haven't ever thought about the case. I see no benefit in waiting for that to happen. And the page that is being blocked, also has no way to abort/close its own request if you were to follow spec because transaction is not set until after blocked has run(!). We've also received comments from internal development teams about this issue. The devs didn't like having an outstanding request that may or may not ever receive a success event. They planned on cancelling their open request if they got a blocked event but, as Odin points out, quickly discovered there was no way to do so. We've talked briefly about adding something like IndexedDB.openOrFail(db, high_version) that would fire a BlockedError if other open connections didn't close in response to versionchange events. So not only will the browser implementation sit around with a useless request (possible several as the page retries or the user opens up more windows) - but also the page itself can't be a good citizen and clean up for itself (well, as long as they forgot to close in versionchange). So in the case of being blocked, it would be nicer to have the new page open request (or delete) get an error event, maybe something like BlockedError. It can then show the user «Please close the other window and [retry]». Also, there's a much bigger chance of developers listening to error on the opening page, rather than blocked. +1. Replacing blocked event with an error event named BlockedError would be an improvement. As for what implementations do now, based on the very simple tests I did, Firefox seems to follow the spec as if it was written based on that implementation (:P) - IE10 doesn't send fire a versionchange request at all, but it does do blocked. So I guess IE would rather quickly run into compat problems. It does however fire the blocked event on the opening page, although it's not really useful for much as far as I can see. What do you think? PS: In *any* case, those issues should be resolved some way, I just think simplifying such a corner case would be very beneficial. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [IndexedDB] blocked event could be an error
On Thu, Jul 26, 2012 at 2:59 PM, David Grogan dgro...@chromium.org wrote: On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal odi...@opera.com wrote: There are some open issues in the spec that has been there a long time. They deal with opening and deleting database. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database # 7. Wait until all objects in openDatabases are closed and all of their #transactions are finished. # #ISSUE: Should we allow blocked to be fired here too, if waiting takes #too long? # # 8. Delete db. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction # 4. Wait until either all objects in openDatabases are closed and all of #their transactions are finished. # #ISSUE: If .close() is called immediately but a transaction associated # with the connection keeps running for a long time, should we # also fire a blocked event? # #ISSUE: If, while we're waiting here, someone calls open with a # version number higher than version, we should probably let # that upgrade run first and bail here if it was successful. To be very honest, the whole blocked and then wait-system seems very over the top for a small benefit. IMHO the harm is greater than any potential small benefit. We'd have to keep lots of requests indefinitely open. If the other page having an open database doesn't clean up and db.close() in its db.versionchange handler, most definitely the developer haven't ever thought about the case. I see no benefit in waiting for that to happen. And the page that is being blocked, also has no way to abort/close its own request if you were to follow spec because transaction is not set until after blocked has run(!). We've also received comments from internal development teams about this issue. The devs didn't like having an outstanding request that may or may not ever receive a success event. They planned on cancelling their open request if they got a blocked event but, as Odin points out, quickly discovered there was no way to do so. We've talked briefly about adding something like IndexedDB.openOrFail(db, high_version) that would fire a BlockedError if other open connections didn't close in response to versionchange events. I definitely think that we need to keep the blocked events as non-error events since it supports the use case of opening a connection and displaying UI to the user asking that other tabs are closed if the blocked event fires. However the use cases brought up here makes sense. I think we can solve this in two ways: Add a .abort() method to IDBOpenDBRequest. This would cause an error event to be fired immediately (but asynchronously) and the attempt to open the database to be canceled. Add a openOrFail method in addition to the existing open method. openOrFail would automatically abort the attempt to open the database as soon as blocked is fired. Instead an error event would immediately be fired. However is this something that we can wait with until v2? Punting something to v2 doesn't mean that implementation needs to hold off implementing until v2 is finished, but it means that we should start an official v2 draft sooner rather than later. I don't have a strong opinion either way. / Jonas
Re: [IndexedDB] blocked event could be an error
I definitely think that we need to keep the blocked events as non-error events since it supports the use case of opening a connection and displaying UI to the user asking that other tabs are closed if the blocked event fires. That can very well be achieved by detecting the BlockedError, and adding a retry button which calls open() again. If you really want a open() and wait forever behavior, that should not be the default one.
Re: [IndexedDB] blocked event could be an error
On Thu, Jul 26, 2012 at 3:28 PM, João Eiras jo...@opera.com wrote: I definitely think that we need to keep the blocked events as non-error events since it supports the use case of opening a connection and displaying UI to the user asking that other tabs are closed if the blocked event fires. That can very well be achieved by detecting the BlockedError, and adding a retry button which calls open() again. If you really want a open() and wait forever behavior, that should not be the default one. I'm not at all comfortable with changing the default behavior this late in the process. / Jonas
[IndexedDB] blocked event could be an error
There are some open issues in the spec that has been there a long time. They deal with opening and deleting database. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database # 7. Wait until all objects in openDatabases are closed and all of their #transactions are finished. # #ISSUE: Should we allow blocked to be fired here too, if waiting takes #too long? # # 8. Delete db. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction # 4. Wait until either all objects in openDatabases are closed and all of #their transactions are finished. # #ISSUE: If .close() is called immediately but a transaction associated # with the connection keeps running for a long time, should we # also fire a blocked event? # #ISSUE: If, while we're waiting here, someone calls open with a # version number higher than version, we should probably let # that upgrade run first and bail here if it was successful. To be very honest, the whole blocked and then wait-system seems very over the top for a small benefit. IMHO the harm is greater than any potential small benefit. We'd have to keep lots of requests indefinitely open. If the other page having an open database doesn't clean up and db.close() in its db.versionchange handler, most definitely the developer haven't ever thought about the case. I see no benefit in waiting for that to happen. And the page that is being blocked, also has no way to abort/close its own request if you were to follow spec because transaction is not set until after blocked has run(!). So not only will the browser implementation sit around with a useless request (possible several as the page retries or the user opens up more windows) - but also the page itself can't be a good citizen and clean up for itself (well, as long as they forgot to close in versionchange). So in the case of being blocked, it would be nicer to have the new page open request (or delete) get an error event, maybe something like BlockedError. It can then show the user «Please close the other window and [retry]». Also, there's a much bigger chance of developers listening to error on the opening page, rather than blocked. As for what implementations do now, based on the very simple tests I did, Firefox seems to follow the spec as if it was written based on that implementation (:P) - IE10 doesn't send fire a versionchange request at all, but it does do blocked. So I guess IE would rather quickly run into compat problems. It does however fire the blocked event on the opening page, although it's not really useful for much as far as I can see. What do you think? PS: In *any* case, those issues should be resolved some way, I just think simplifying such a corner case would be very beneficial. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
