W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] Constants and interfaces

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 31 Aug 2010 12:03:00 -0700
Message-ID: <AANLkTimjj7QkEq+45-AOdQZ9883fquP2QuKZANBBsXvU@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: public-webapps WG <public-webapps@w3.org>
On Tue, Aug 31, 2010 at 4:41 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> 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?

I can't say that I care much. Adding it to WebIDL seems fine, though I
also could see the argument that if no other classes than IDBKeyRange
needs multiple constructors, then there isn't much value to adding it
to WebIDL.

But I'm all for proposing it for inclusion in WebIDL.

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

No disadvantages other than less nice syntax.

x = indexedDB.createLeftBoundKeyRange(...);
vs
x = IDBKeyRange.leftBound(...);

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

Java.

Though I really really really want to get out of the thinking that the
interfaces we are creating needs to work as well in other languages as
they do in javascript. I really think there has been very little value
in having the Node family of interfaces work as well in java as they
do in javascript.

Furthermore, I don't think it's possible to design truly language
agnostic interfaces. For example, after having implemented the Node
family of interfaces in C++ for several years, I can tell you they are
not very well suited for C++.

So IMHO we should heavily optimize for javascript, while ensuring that
other languages are possible.

/ Jonas
Received on Tuesday, 31 August 2010 19:03:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT