W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Some IndexedDB feedback

From: Jeremy Orlow <jorlow@chromium.org>
Date: Sat, 30 Jan 2010 17:38:56 -0800
Message-ID: <5dd9e5c51001301738v3b155176ud0b272e4619a8b79@mail.gmail.com>
To: public-webapps@w3c.org
I've started work on implementing the IndexedDB bindings in WebKit as a way
to sanity check the API.  I figure it's easiest to trickle feedback to this
list rather than save it all up for a big thread, but I'm happy to do that
if it's preferred.

Interfaces I've looked at so far:
IDBEnvironment
IndexedDatabaseRequest
IDBRequest
IDBDatabaseError
IDBDatabaseException


First of all, I just wanted to say that I found the event based nature of
IndexedDatabaseRequest/IDBRequest fairly cumbersome.  Why not just have open
take in a onsuccess and onerror callbacks and return an object which has the
ready state, an abort method, and maybe an error code?  It seems as though
the event based API is actually more confusing and artificially limiting
(only one open request in flight at a time) than is necessary.

I assume that the limitation is only one database _opening_ in flight at
once, and not a limitation that you can only have one database open ever?

What is IDBRequest.error when there is no error?  null?  When would it be
reset?  The next time you call open?

What happens when you call abort and there is no pending open?  Is it a
no-op?

Is it really necessary to have a separate IDBDatabaseException and
IDBDatabaseError?  I know one is technically an exception and one is
technically an interface, but it seems a bit silly.  Also, it seems as
though they both share the same codes, but the codes are only defined in
IDBDatabaseException?  If so, I'm not sure it's clear enough in the spec.

But really, does IndexedDB really need its own error and exception classes?
 At very least, I know the WebSQLDB spec has a very similar error class.
 And I suspect there are others, though I didn't immediately find anything
looking through the HTML5 spec.  Maybe these types of interfaces should be
specified in parent specs and not duplicated in those that depend on them?

In 3.4.5 probably means to say "events" rather than "callbacks" in the first
sentence.

In 3.4.2, queue is mispelled as "aueue".


That's all I have for now.  I've skimmed over the whole spec but only read
carefully these sections, so please excuse me if any of my questions can be
answered from text elsewhere in the spec.  (Though maybe it would be a sign
that the relevant sections should be more clear?)

Thanks!
J
Received on Sunday, 31 January 2010 01:42:48 GMT

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