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

Right. But is there anything one loses by not relying on it, by making the API more generic?

On Dec 30, 2010, at 7:58 , Jonas Sicking wrote:

> On Wed, Dec 29, 2010 at 2:44 PM, Axel Rauschmayer <axel@rauschma.de> wrote:
>> 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.
> 
> Note that almost everyone relies on this anyway. I bet that almost all
> code out there depends on that the code in for example onload handlers
> for XHR requests run after the current thread of execution has fully
> finished.
> 
> Asynchronous events isn't something specific to javascript.
> 
> / Jonas
> 

-- 
Dr. Axel Rauschmayer
Axel.Rauschmayer@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/

Received on Thursday, 30 December 2010 08:46:19 UTC