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, 24 Aug 2010 12:19:36 -0700
Message-ID: <AANLkTim0cO3hk3WrkutP95Zq39oQZnxM5WYOSCnh8hL-@mail.gmail.com>
To: Andrei Popescu <andreip@google.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
On Tue, Aug 24, 2010 at 10:58 AM, Andrei Popescu <andreip@google.com> wrote:
> On Tue, Aug 24, 2010 at 6:30 PM, 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.
>> 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?
>> 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.
> I wonder if it would make sense to group all constants into a separate
> interface, which would have an interface object. The rest of the
> interfaces would all be defined with [NoInterfaceObject]. What do you
> think?

I would prefer to stick to how things are done elsewhere and put
constants on relevant interfaces.

We likely do *not* want [NoInterfaceObject] on almost all interfaces
anyway. Interface objects are useful to allow pages to extend
prototypes and adding functions, for example adding back something
similar to db.objectStore which we're killing.

The only thing in the async API that I can see which should have
[NoInterfaceObject] is IDBEnvironment.

/ Jonas
Received on Tuesday, 24 August 2010 19:20:33 UTC

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