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

This is very similar


window.indexedDB.open(..., {
    onsuccess: function(event) { ... };
});


Except it requires an extra level on indenting for the callback definitions.
In both this and the current implementation there is the additional overhead
of an object creation for every call, when compared to simply having plain
function arguments:


window.indexedDB.open(..., function(event) { ... });


However just parsing the callback as a function argument does not make it as
clear what is happening when reading the code.



There may be a point in making this more generic. As there is only a single
thread there is no way any callback code can be executed while the current
function does not return. Consider:


var f = function() {
    setTimeout(function g() {...}, 1000);
    while(true) {};
};


In this code the 'g' will never get called... how can it when the single
thread is busy in the while loop? Technically this could be possible if the
interpreter implemented interrupts and continuations, so that the timeout
stops the JS interpreter which saves a continuation allowing it to resume
later and then executes the callback in a fresh context. However interpreter
level continuations are not a feature of standard JavaScript. If interpreter
continuations were implemented they would break the current API... This
could be fixed by deferring the execution of the initial function like so:


var request = window.indexedDB.open(...); // request object stores
parameters (maybe some pre-comutation is done).
request.onsuccess = function(event) { ... }; // set callback
request.run(); // execute the part of the open function that can cause the
callback.


So this would keep the current style, but also be more generic.


Cheers,
Keean.


On 30 December 2010 08:45, Axel Rauschmayer <axel@rauschma.de> wrote:

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