Re: [IndexedDB] Constants and interfaces

On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> 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?
>
> It's possible, sure, but is anything like this done on any other API?  If
> not, I'd rather not reinvent the wheel here.  To me, adding factory methods
> to IDBFactory seems more natural.  I don't see any real disadvantages to
> accessing methods off of |indexedDB| rather than |IDBKeyRange|.  I
> especially don't like the idea of some languages putting methods on the
> IDBFactory interface and some implementing them as static methods on
> IDBKeyRange, which might be unavoidable with what you're proposing?
> It'd be nice to hear what others think about this, btw.

I don't think we should be afraid of doing things that are unheard of
in the DOM. We've already introduced methods that accept arrays
(.transaction()) and talked about introducing methods that take
"property bag"-like objects. Neither of which have been done in the
DOM before.

Further, javascript already has similar concepts, like the
Array.concat('a', 'b') constructor. So it won't be that new for JS
developers.

/ Jonas

Received on Saturday, 28 August 2010 22:27:23 UTC