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: Mon, 27 Feb 2012 16:13:49 +0100
Message-ID: <CA+c2ei_pqE10FJ27CMfcXj9irhJPrs7f27LUZu2ywnDOYgGGkQ@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>
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.


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"

/ Jonas
Received on Monday, 27 February 2012 15:14:58 UTC

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