Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

2011-01-28 Thread Axel Rauschmayer
APIs (= not me, but possibly anyone of you or anyone at Mozilla, MS, Google). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com

Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

2011-01-28 Thread Axel Rauschmayer
was confused, because IDBRequest plays double duty. To me an event is something that is created at the event emitter and directly sent to event handlers, without exposing it inbetween. That is too narror and IDBRequest is indeed an event. -- Dr. Axel Rauschmayer a...@rauschma.de Home: http

Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

2011-01-28 Thread Axel Rauschmayer
for DOM elements, custom DOM events for a complete web page, etc.). -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com

Re: An HTML5 logo

2011-01-22 Thread Axel Rauschmayer
://datadriven.com.au -- Dr. Axel Rauschmayer a...@rauschma.de Home: http://rauschma.de Blog: http://2ality.com

Re: [IndexedDB] Events and requests

2011-01-11 Thread Axel Rauschmayer
: Comments inline: On 11 January 2011 07:11, Axel Rauschmayer a...@rauschma.de wrote: Coming back to the initial message in this thread (at the very bottom): = General rule of thumb: clearly separate input data and output data. Using JavaScript dynamic nature, things could look as follows

Re: [IndexedDB] Events and requests

2011-01-10 Thread Axel Rauschmayer
-- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/

Re: [IndexedDB] Events and requests

2011-01-10 Thread Axel Rauschmayer
it on to some people I know who are playing with IndexedDB already. J -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/

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

2010-12-30 Thread Axel Rauschmayer
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 a...@rauschma.de wrote: Can someone explain a bit more about the motivation behind the current

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

2010-12-30 Thread Axel Rauschmayer
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.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/

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

2010-12-30 Thread Axel Rauschmayer
.) -- Glenn Maynard -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/

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

2010-12-29 Thread Axel Rauschmayer
* 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. Thanks! Axel -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free