Re: [IndexedDB] Constants and interfaces

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