Can someone explain a bit more about the motivation behind the current design
of the async API?
> var request = window.indexedDB.open(...);
> request.onsuccess = function(event) { ... };
The pattern of assigning the success continuation after invoking the operation
seems to be to closely tied to JavaScript’s current run-to-completion event
handling. But what about future JavaScript environments, e.g. a multi-threaded
Node.js with IndexedDB built in or Rhino with IndexedDB running in parallel?
Wouldn’t a reliance on run-to-completion unnecessarily limit future
developments?
Maybe it is just me, but I would like it better if the last argument was an
object with the error and the success continuations (they could also be
individual arguments). That is also how current JavaScript RPC APIs are
designed, resulting in a familiar look. Are there any arguments *against* this
approach?
Whatever the reasoning behind the design, I think it should be explained in the
spec, because the current API is a bit tricky to understand for newbies.
Thanks!
Axel
--
Dr. Axel Rauschmayer
[email protected]
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
