- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Sat, 30 Jan 2010 17:38:56 -0800
- To: public-webapps@w3c.org
- Message-ID: <5dd9e5c51001301738v3b155176ud0b272e4619a8b79@mail.gmail.com>
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 UTC