[IndexedDB] Why rely on run-to-completion?

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
Axel.Rauschmayer@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/

Received on Wednesday, 29 December 2010 22:45:25 UTC