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, 1 Mar 2012 02:23:09 +0100
Message-ID: <CA+c2ei_VZ0aK99JyJ2Tz6e7ZQki0NbWsijcq3jbS5xiM48fVgA@mail.gmail.com>
To: Odin Hørthe Omdal <odinho@opera.com>
Cc: Simon Pieters <simonp@opera.com>, Israel Hilerio <israelh@microsoft.com>, Joshua Bell <jsbell@chromium.org>, "public-webapps@w3.org" <public-webapps@w3.org>, Ben Turner <bent@mozilla.com>
On Mon, Feb 27, 2012 at 4:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Feb 27, 2012 at 1:44 PM, Odin Hørthe Omdal <odinho@opera.com> wrote:
>> On Sat, 25 Feb 2012 00:34:40 +0100, Israel Hilerio <israelh@microsoft.com>
>> wrote:
>>
>>> We have several internal and external teams implementing solutions on
>>> IndexedDB for IE10 and Win8.  They are looking for a finalized spec sooner
>>> than later to ensure the stability of their implementations.  Every time we
>>> change the APIs, they have to go back and update their implementations.
>>>  This activity sets them back and makes them loose confidence in the
>>> platform.
>>
>>
>> Hmmmm...
>>
>> If you implement the fallback that Sicking mentioned, just changing the
>> value of the e.g. IDBTransaction.READ_WRITE from 1 to "read-write" (or
>> whatever we'll choose to call it), then all that code will continue to work.
>>
>> It can be treated like an internal change. All the code I've seen from
>> Microsoft so far has used the constants (which is how it's supposed to be
>> used anyway) - so updating then won't be necessary.
>>
>>
>> This is a change for the huge masses of people which will come after us and
>> *not* be as wise and just input 1 or 2 or whatever that doesn't tell us
>> anything about what the code is doing.
>>
>> IMHO it's a very small price to pay for a bigger gain.
>
> Israel,
>
> I sympathize and definitely understand that this is a scary change to
> make so late in the game.
>
> However I think it would be a big improvement to the API. Both from
> the point of view of usability (it's a lot easier to write "readwrite"
> than IDBTransaction.READ_WRITE) and from the point of view of
> consistency with most other JS APIs that are now being created both
> inside the W3C and outside it.
>
> As has been pointed out, this change can be made in a very backwards
> compatible way. Any code which uses the constants would continue to
> work just as-is. You can even let .transaction() and .openCursor()
> accept numeric keys as well as the string-based ones so that if anyone
> does db.transaction("mystore", 2) it will continue to work.
>
> The only way something would break is if someone does something like
> "if (someRequest.readyState == 2)", but I've never seen any code like
> that, and there is very little reason for anyone to write such code.
>
>
> To speed up this process, I propose that we use the following values
> for the constants:
>
> IDBDatabase.transaction() - mode:  "readwrite", "readonly"
> *.openCursor() - direction: "next", "nextunique", "prev", "prevunique"
> IDBRequest.readyState: "pending", "done"
> IDBCursor.direction: same as openCursor
> IDBTransaction.mode: "readwrite", "readonly", "versionchange"

I talked to Israel and got a preliminary ok from microsoft about
putting this into the spec. I'll go ahead and do that tomorrow (CET)
so if anyone wants to go ahead an bikeshed about the names now is the
time to do so. But I'm inclined to go ahead with the current
suggestion since it seems to have enough consensus.

I'll remove the constants from the IDL but will leave a non-normative
comment in there about that they used to be there as to help authors
for some time going forward.

/ Jonas
Received on Thursday, 1 March 2012 01:24:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT