Re: [IndexedDB] Constants and interfaces

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.

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?

J