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