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

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

See point (3) below.

>> 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).

I'm sorry for coming so late to this discussion, this gives my arguments less weight and means that I might be rehashing what has already fbeen said. From what I could find, it was web developers arguing in favor of an event-based interface. Usually, event-based APIs are structured as follows (with the only(?) exception of XMLHttpRequest):

- register an event listener at a *fixed* source.
- wait for events being sent from outside. You don’t cause the events, an external entity (such as the user) does.

This is a bus metaphor and very intuitive, but it does not apply in the case of APIs and becomes much less intuitive:
(1) *dynamically* create the source of events and cause an event at the same time
(2) Register the event listeners
(3) Depend on run-to-completion semantics and the event queue to start the operation. This mixes a user interface queue with a programming API. Furthermore, one never explicitly starts the operation, only implicitly. I think the async API is interesting in non-UI contexts (e.g. a future multi-threaded JavaScript), then you need to explicitly start the operation and cannot rely on either run-to-completion semantics or the UI event queue (right?).

I think Ajax RPC APIs are a much better metaphor, instead of the server, you send requests to IndexedDB. One could also go full-on bus, but with different invocation sequences that cause the same kinds of events, this would quickly become ugly.

One additional possibility, that has already been discussed, are futures [1]. If each operation returned a future, then one has the chance of registering listeners etc. The only thing that would change is an explicit method (such as run() or get()) to start the operation. I can also imagine a convenience method run() that takes callbacks.

[1] http://en.wikipedia.org/wiki/Futures_and_promises

For example:
window.indexedDB.open(...)
.addOnSuccess(function() {...})
.addOnFailure(function() {...})
.run();

I wonder if the requirement of multiple listeners for the result (that comes from web developers) does not unnecessarily mix two concerns: First, invoking the API. Second, distributing model data to UI components.

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

Right. How about a separate document that collects the design rationales? I find those tremendously useful. They prevent fruitless discussions and the repetition of mistakes (e.g. in future versions of an API or similar APIs).

To summarize: This API design goes against every non-browser API  I have seen in my 25 years of programming. I expect JavaScript to become *the* mainstream programming language before long and IndexedDB to play an important role in that. Thus, staying closer to the mainstream and enabling future extensions is (IMHO) an important consideration. Going the "futures" route mentioned above would do that and only require minor changes to the API.

Comments?

Axel

-- 
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 17:21:35 UTC