Re: [IndexedDB] Numeric constants vs enumerated strings

This is now fixed in editor drafts. I still need to add the
non-normative text for authors. I'll try to work up some wording this
weekend.

/ Jonas

On Thu, Mar 1, 2012 at 2:23 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 Friday, 2 March 2012 02:30:45 UTC