Hi all,
Sorry to be slow in responding to all the feedback on Indexed DB. As
you know, this is now my unpaid work and I am trying my best to
respond to comments before the weekend is up.
But this is good. Please keep the feedback and early implementation
experience coming.
On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote:
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.
I prefer to get incremental comments unless there is a major hole in
the spec and you need time to digest it and prepare a comprehensive
proposal
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.
Every approach has its pros and cons. More than with other APIs, a
database API that is all three - low-level, easy to program, and
asynchronous - is not easy to get. I don't know for sure that we can
satisfy all three. I am going to take one more crack at this and have
this item on my to-do list.
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?
Correct. Only one _in-flight_ request on an object. If we had a
DataCache-style API, every synchronous call would return a result, and
an asynchronous call would return a "promise". It would be more
flexible, but no easier to deal with.
What is IDBRequest.error when there is no error? null? When would
it be reset? The next time you call open?
I have clarified this. Any time request is in INITIAL or LOADING
state, error is null. It would be reset whenever the request
transitions from DONE back to LOADING state.
What happens when you call abort and there is no pending open? Is
it a no-op?
No-op is the correct behavior.
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.
Do you have a Web IDL proposal for this? I would love to be correct
and satisfy you. However, I am not an expert in the business of WebIDL.
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.
XHR defines codes, but no new exceptions. File API has both and a
style similar to Indexed Database
Maybe these types of interfaces should be specified in parent specs
and not duplicated in those that depend on them?
I am willing to go with whatever works for everyone.
In 3.4.5 probably means to say "events" rather than "callbacks" in
the first sentence.
Yes
In 3.4.2, queue is mispelled as "aueue".
Gotcha
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
