- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 27 Aug 2010 11:00:33 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-webapps WG <public-webapps@w3.org>
On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow <jorlow@chromium.org> wrote: >> > On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> >> >> On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow <jorlow@chromium.org> >> >> wrote: >> >> > Last we spoke about constants in IndexedDB, (like >> >> > IDBKeyRange.LEFT_BOUND) I >> >> > believe we had decided that all the objects with constants would have >> >> > an >> >> > interface object hanging off of window so it's possible to simply say >> >> > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when >> >> > someone >> >> > tries >> >> > something like the following JS: |IDBCursor.continue()|? Given that >> >> > we're >> >> > using an interface object, I'd assume we throw some sort of exception >> >> > or >> >> > something? I tried to figure out the answer in the WebIDL spec (I >> >> > imagine >> >> > it's somewhere around >> >> > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but >> >> > it's a >> >> > lot to wade through. Any advice would be great. >> >> >> >> I definitely think we should handle this the same way that all other >> >> interfaces does it. I.e. the same way that >> >> window.Node.appendChild(...) does it. In the Firefox implementation we >> >> just fall back to using our generic code for all this stuff, so >> >> nothing special goes on in the IndexedDB implementation. >> >> >> >> And yes, I think WebIDL should be the one defining what should happen. >> >> If it doesn't already someone should file a bug :) >> > >> > Ok, I figured out how interface objects are done in WebKit and got it >> > implemented. And everything looks like it's working fine except for >> > IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods >> > attached >> > to it, but these aren't accessible from the interface object (and these >> > factories are the only possible way to get such an object). It makes >> > sense >> > that methods are by default not considered static (i.e. must be called >> > on an >> > instance of the interface). >> >> Indeed, the factory methods on IDBKeyRange use a different syntax from >> every other method in the DOM. This was why we originally proposed a >> different syntax in our proposal. >> >> However I've come to like the current specced syntax quite a bit and >> would prefer to stick to it actually. It makes for a lot nicer >> javascript. We might want to change left/right bound to lower/upper >> bound, but other than that I'd prefer to stick to the current syntax. >> It does take some trickery to implement in gecko, but not enough to >> toss it out IMHO. > > This isn't just an issue of implementation "trickery". What's specced > doesn't work. Leaving it as is is not an option. Agreed. > We either need to figure out the right language to describe what we intended > or we need to change it. As I mentioned, I tried to figure out what was > needed spec wise, but couldn't. As far as I can tell, there isn't anything > else out there trying to do this either, so it's very possible this behavior > would require a change to the WebIDL spec. (And blocking on that > is probably not a good idea given that it's been stagnant for so long and > has quite a backlog of required changes at this point.) > Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? / Jonas
Received on Friday, 27 August 2010 18:01:22 UTC