Re: [IndexedDB] Constants and interfaces

On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>

I think I'd only support this if it was just a stop-gap measure until WebIDL
could add proper support.  Is there any way to bring this up with those
folks and get their feelings on the subject so whatever we do
is consistent with the future directions of that spec?


> >> 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
>

Are there any specific disadvantages to adding items to indexedDB, or is
your concern simply that it's more clear to put "static" methods on
IDBKeyRange?

> 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?
>

Are there languages that would not be able to implement this static method
concept?  If so, that'd be a deal breaker.  I'm not really a PL expert tho.


> > 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.


To be honest, I'm not really sure why you think it's so important to fight
this uphill battle rather than put the factory methods on IDBFactory.  But
assuming my concerns above are addressed, I'm fine with us going the static
method direction.

J