Re: [IndexedDB] API feedback

-----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)? 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.
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 Friday, 12 March 2010 17:53:58 UTC