On Thursday, February 23, 2012 4:49 AM, Jonas Sicking wrote: > On Thu, Feb 23, 2012 at 1:09 PM, Simon Pieters <sim...@opera.com> > wrote: > > On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal > > <odi...@opera.com> > > wrote: > > > >> On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking <jo...@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 >
We don't believe it is a good idea to make this change to the spec at this time. 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. While there are many incremental API improvements we can make to the existing spec, we believe that the current spec provides a reasonable implementation that we can ship a v1 with. I believe we can discuss this proposal and others at a later time as part of IDB v2. Like each one of you, we're looking for an interoperable solution these customers can take advantage of. To that effect, we're in the process of updating the spec to incorporate most of the bug feedback provided by the community to date. Ideally, we would like to start the Last Call process in March. In summary, we don't plan to make any more API changes to our current implementation beyond what's on the spec today. While we might be open to some minor internal changes (e.g. sorting order of object store and index names), we're are opposed to these stylistic API changes. Thanks, Israel
