Re: [IndexedDB] API feedback

On Sat, Mar 13, 2010 at 9:44 AM, Nikunj Mehta <nikunj@o-micron.com> wrote:

>
> On Mar 12, 2010, at 9:05 AM, Aaron Boodman wrote:
>
>  Looking at just this snip:
>>
>> function findFred(db) {
>>  db.request.onsuccess = function() {
>>   var index = db.request.result;
>>   index.request.onsuccess = function() {
>>     var matching = index.request.result;
>>     if (matching)
>>       report(matching.isbn, matching.name, matching.author);
>>     else
>>       report(null);
>>   }
>>   index.get('fred');
>>  }
>>  db.openIndex('BookAuthor');
>> }
>>
>> This example is hard to read where the callback is setup before the
>> call like this. Without making any API changes, I think you could
>> improve things:
>>
>> db.openIndex('BookAuthor');
>> db.request.onsuccess = function() {
>>  ...
>> };
>>
>> You just have to make sure that the API guarantees that
>> onsuccess/onfailure will always be called in a separate event, which
>> is important anyway for consistency.
>>
>
> This seems like a light-weight enough requirement that can improve program
> comprehension.
>

I definitely agree that any events/callbacks need to be queued up in the
event loop since possibly executing in a nested fashion will surely lead to
a lot of confusion and bugs.


On Fri, Mar 12, 2010 at 7:13 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:

> On 3/12/2010 9:52 AM, Kris Zyp wrote:
>
>> Would it possibly be more appropriate and expedient to only provide a
>> sync API for now (and defer async support to possibly a later
>> version)? It seems like the design of IndexedDB is such that most
>> operations should occur in O(log n) time, and probably will be easily
>> done under 100ms the majority of the time, and often under 10ms
>> (especially with caching and such). With such short execution times,
>> asynchronous APIs seem less crucial (than XHR for example, that can be
>> very long-running) since IndexedDB blocking times are generally less
>> than a user can perceive (and the concurrency benefits of async would
>> largely be lost on single user browser apps). Anyway, I am not
>> necessarily opposed to an async API, just wondering about the value,
>> especially with the current design being pretty awkward to use as you
>> pointed out.
>>
> Mozilla is *not* interested in implementing a synchronous API on anything
> but a worker thread.  Disk I/O timing is non-deterministic from the
> applications perspective (another app can be writing a bunch of data to disk
> making your reads/writes slow, or fsyncs from another app can flush out the
> entire disk cache on some file systems, etc).
>

Agreed.  Chrome will never implement a sync interface outside of workers.

But I'm not against concentrating on the sync API for now, and revisiting
the async API questions once we're happy with the sync interface.

With that said, I think providing a worker-only API is not ideal.  Not all
> browsers currently implement workers yet, and doing a worker-only API would
> exclude them.
>

There definitely needs to be an async version in v1 of IndexedDB, but it
seems like it'd be OK for v0.1 to gloss over it...if we thought that'd help
the spec development process.

J