W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [IndexedDB] Numeric constants vs enumerated strings

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 23 Feb 2012 13:49:11 +0100
Message-ID: <CA+c2ei_yb1_764KHkfZscNQj11JgfUNBoAZDoDj8SvrbzzVnng@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Joshua Bell <jsbell@chromium.org>, Odin HÝrthe Omdal <odinho@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, Feb 23, 2012 at 1:09 PM, Simon Pieters <simonp@opera.com> wrote:
> On Thu, 23 Feb 2012 10:47:56 +0100, Odin HÝrthe Omdal <odinho@opera.com>
> wrote:
>> On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking <jonas@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.

Yes. I definitely think that we should put just plain strings in the
spec. But implementations can use various tactics to move their
support to that while giving people a migration path.

Of course, I think we need to get Microsoft's approval on this.

/ Jonas
Received on Thursday, 23 February 2012 12:50:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC