[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

Received on Monday, 23 July 2012 17:48:25 UTC