Re: Some IndexedDB feedback

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

Received on Monday, 1 February 2010 08:04:02 UTC