On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking <[email protected]> wrote:
Yes! I would love to make this change.
This is my main peeve with the API as it stands.
Cool! :D
I even think that implementations could remove support for the numbers
by keeping the constants but have them defined to return string
values. I.e.
db.transaction(["store"], IDBTransaction.READ_WRITE);
would continue to work and is the usage pattern that I've seen in all
code that I've looked at.
Ah, that is a very smart idea.
We just had the break of open() with upgradeneeded instead of setVersion.
That's a much bigger break, and if most of us get this in with the same
change - it can just slip nicely in. The code would have to change anyway.
So I think it's not too hard to remove the constants as well. It's
obviously a bit different for Mozilla, since they've shipped their
setVersion killer already, but generally Mozilla is not afraid of changing
stuff if they want to (and it doesn't hurt too much, which IMHO it won't
in this case, sync XHR + CORS is much more painful :P).
The few people who code directly to nightly versions will be used to
changing their code anyway.
Keep supporting the numbers is OK, but a bit strange, given the above
reasons. As long as it's not possible to rely on the numbers, I hope that
developers won't use it anyway, and it'll slowly become obsolete. Then it
can be very easily removed again. Although skipping that dance is of
course even better ;-)
To be honest, I think authors will use the enumerated strings - so if some
implementations do some backwards compat stuff, it'll hopefully become
obsolete.
--
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
