Re: [IndexedDB] API feedback

On Mar 12, 2010, at 9:52 AM, Kris Zyp wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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)?

This is entirely plausible. It is also the reason I have temporarily  
tuned out of most async API questions around IndexedDB.

> 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).

I know that with Berkeley DB, operations are performed in practically  
constant time since the base of the log is pretty high - something  
like 4000. So for all practical purposes, the processing time would be  
very low. In fact, I can hypothesize that the JavaScript context  
switching and event queuing will cost more than the I/O.

> 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.

As I indicated in a previous email, the search for a good async API  
should not block progress on the rest of the API.

> Kris
>
> On 3/12/2010 10:05 AM, Aaron Boodman wrote:
>> I haven't been following the discussion with IndexedDB closely, but I
>> think the general ID of an indexed name/value store is a great idea,
>> and would be Good for the web.
>>
>> However, I do agree with Jeremy that the current shape of the API is
>> too confusing. Maybe I can be useful as a new set of eyes.
>>
>> 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.
>>
>> I think it's counter-intuitive to have a single 'request' object per
>> database. Even though it might be technically true that in
>> single-threaded JavaScript that is the reality. A request describes
>> something that there are many of, that doesn't get reused. Reusing  
>> the
>> single onsuccess event also seems like something that is likely to
>> cause bugs (people forgetting to reset it correctly, an old callback
>> gets fired). Finally, developers might be used to XHR, where there  
>> are
>> of course multiple requests.
>>
>> So I think one improvement could be create one request for each  
>> logical
> request:
>>
>> function findFred(db) {
>>  var req1 = db.openIndex('BookAuthor');
>>  req.onsuccess = function() {
>>    var index = req1.result;
>>    var req2 = index.get('fred');
>>    req2.onsuccess = function() {
>>      ...
>>    }
>>  }
>> }
>>
>> Like I said, I've only thought about this for a moment. I know how
>> hard API design can be, and these are my drive-by first-blush
>> comments. But on the other hand, sometimes drive-by, first-blush
>> comments are useful for figuring out APIs.
>>
>> HTH,
>>
>> - a
>>
>
> - --
> Kris Zyp
> SitePen
> (503) 806-1841
> http://sitepen.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuaf1gACgkQ9VpNnHc4zAwnQwCeMx2iLFEnUdBNiEfKoA339snl
> qSUAoKUfZBkLQkhzcN9GzFJF+i9TprvB
> =vUQ5
> -----END PGP SIGNATURE-----
>

Received on Saturday, 13 March 2010 09:17:24 UTC