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

Re: [IndexedDB] Constants and interfaces

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 25 Aug 2010 14:45:51 +0100
Message-ID: <AANLkTin5n_pBu1b5gmeB5hGRCzopMGhDWo-W=0x1Teug@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps WG <public-webapps@w3.org>
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).  But is there any way to override this behavior
or can anyone point to other examples where this is done?

Of course another option is to move the factory methods to IDBFactory (as
was suggested earlier).  This would just work since window.indexedDB()
returns an IDBFactory object.  If no one has any bright ideas about how to
otherwise spec what's there, I'd suggest we make that change.

I tried to figure all of this out on my own by reading the WebIDL spec, but
I've found it almost impossible to digest.  :-(

>  > Also, the spec still has "[NoInterfaceObject]" for a lot of the
> interfaces.
> >  I believe Nikunj did this by accident and was supposed to revert, but I
> > guess he didn't?  I should file a bug to get these removed, right?
> Please do.


> > Another question: Right now all the error constants are on
> > IDBDatabaseException which is an exception rather than an interface.  Is
> > this allowed?  And even if so, should we put them on IDBDatabaseError
> > instead, given that it's the class people will be using more often (with
> the
> > async interface)?  Or maybe we should duplicate the constants in both
> > places?  It just feels weird to me that I keep reaching into
> > IDBDatabaseException for these constants.
> Exception stuff has always confused me, but I think this is how idl
> elsewhere does it.

Ok, I guess we'll leave it then.

Received on Wednesday, 25 August 2010 13:46:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC