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 <[email protected]> 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 [email protected] http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
