W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Axel Rauschmayer <axel@rauschma.de>
Date: Thu, 30 Dec 2010 23:58:13 +0100
Message-Id: <B8394B65-A904-4F18-84DE-7CF4FE25A12D@rauschma.de>
To: public-webapps@w3.org
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
### Hyena: organize your ideas, free at hypergraphs.de/hyena/
Received on Thursday, 30 December 2010 22:58:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC