Re: Some IndexedDB feedback

On Mon, Feb 1, 2010 at 12:02 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:

> 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'll try to think about this as well and offer some suggestions as I gain
further experience with the API.

 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.


I'm pretty sure you know more WebIDL than me.  Maybe there are other experts
on the list that can offer some suggestions.

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.


Can any spec/IDL experts offer any suggestions here?


Thanks again, Nikunj

J