RE: [IndexedDB] Numeric constants vs enumerated strings

Anne,

That is certainly one point of view.  However, we've been collecting features for a v2 since before June of 2011 [1].  To that effect, we've had several email exchanges between the WG members where we agree to defer work for v2 (see [2], [3], etc.).  That tells me that our working group is committed to delivering a v1 version of the spec.  Furthermore, the fact that we have a v2 list doesn't invalidate the functionality we defined in v1.  For example, there is no reason why the change you are proposing couldn't be introduced in v2 and still be backwards compatible with our legacy code.

It is our belief based on internal feedback and external partner feedback that the technology will remain un-deployed and in draft form if we continue to make changes like this.

Israel

[1] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0534.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0942.html

On Monday, February 27, 2012 8:38 AM, James Robinson wrote:

Also note that however painful an API change may seem now, it will only get more painful the longer it is put off.

- James
On Feb 27, 2012 7:50 AM, Odin Hørthe Omdal <odinho@opera.com<mailto:odinho@opera.com>> wrote:

I agree on the values. +1

--
Sent from my N9, excuse the top posting


On 27.02.12 16:17 Jonas Sicking wrote:
On Mon, Feb 27, 2012 at 1:44 PM, Odin Hørthe Omdal <odinho@opera.com<mailto:odinho@opera.com>> wrote:
> On Sat, 25 Feb 2012 00:34:40 +0100, Israel Hilerio <israelh@microsoft.com<mailto: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"

/ Jonas