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

I think my main complaint boils down to aesthetics. I don’t expect the event metaphor when I see API invocations, I expect the callback metaphor (used by RPC APIs in Dojo, GWT, etc.). Or, if the event metaphor is used, it has the following clearly delineated stages:
(1) Create an event source
(2) Register observers/listeners
(3) Start event production

(3) is implicit and you have to know about the event queue to understand it. I also wonder if multiple listeners ever make sense, don’t they complicate things on the IndexedDB side? Can the same IDB result be read multiple times?

I am aware that it is difficult to argue about aesthetics, but given that a few people were already confused about the API (fearing a race condition), a change might make things easier to understand.

I can also imagine myself remoting database invocations, RPC-style, if, say, a CouchDB server is currently online and using IndexedDB, otherwise. Having the same API style in both instances would help.

On Dec 30, 2010, at 23:43 , Glenn Maynard wrote:

> On Thu, Dec 30, 2010 at 5:19 PM, Keean Schupke <keean@fry-it.com> wrote:
>> I think keeping away from multi-threading in JS is sensible (perhaps Erlang
>> style multi-processing would be good though). However "interrupting" the
>> interpreter to process callbacks is just a single thread and causes no
>> problems providing the callbacks are initialised before the call that
>> initialises the background process that will generate the asynchronous
>> event.
> 
> Delivering events between VM bytecodes is very similar to threading:
> it makes code much less deterministic, causing many of the same
> problems: race conditions depending on where operations and events
> intersect.
> 
> For example, it's very hard in most high-level languages to deal
> consistently with asynchronous exceptions: exceptions which can happen
> after any bytecode operation.  An example is KeyboardInterrupt in
> Python.  It's very difficult to fully test, and leads to bugs that
> are, just like thread races, very hard to reproduce, ultimately
> because rather than having a fixed set of branch points to test, you
> have as many branches as you have opcodes.
> 
> (By the way, this is why in the synchronous events thread my
> suggestion was a function to deliver events, keeping the points where
> events can be delivered precisely defined; not something like an
> "allow delivery at any time" flag.)
> 
> -- 
> Glenn Maynard
> 
> 

-- 
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 22:58:44 UTC