On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal <odi...@opera.com>
wrote:
On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking <jo...@sicking.cc>
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.
I think if we want the end result to be strings only, the best way to get
there is for everyone to remove support for constants and numbers at the
same time as they implement support for strings.
--
Simon Pieters
Opera Software
