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

On 12/29/2010 2:44 PM, Axel Rauschmayer wrote:
> 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?
Could you elaborate on how the current spec would fall-apart without 
run-to-completion semantics?  Preferably with specific examples.

> 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?
Right now we support having multiple callbacks by registering multiple 
listeners for the event (with addEventListener).  Using an object would 
limit us to one callback.  There is a thread somewhere in this group 
where we decided to go with an event-based API instead of a callback one 
(I cannot recall the reasons off the top of my head).

> 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.
I do not think that a spec is the right place to justify design decisions.

Cheers,

Shawn