W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: Axel Rauschmayer <axel@rauschma.de>
Date: Fri, 28 Jan 2011 10:15:52 +0100
Message-Id: <6E30425E-F0C9-4D8A-B6A0-3A26AEABE1E9@rauschma.de>
Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps@w3.org
To: Jonas Sicking <jonas@sicking.cc>
> Also note that the reason that your suggestion removes the need for
> readyState is that your proposal decides to drop support for the
> use-case that readyState aims to help solve. I.e. the ability to
> register additional event handlers sometime after the request is
> created.

All API invocations that I have seen relied on run-to-completion semantics and add a listener after the initial invocation. These now have to check the flag?

Note that one can create the event emitter (and register handlers) before invoking an operation.

> 
>> Then IDBRequest would be more like an event, right? It would be sent to the onsuccess and onerror event handlers.
> 
> I don't understand what you mean here. But in the current model (both
> the one that's in the spec right now, and the one that I'm proposing)
> we're using real DOM-Events. Can't really get more "like events" than
> that?


Right, Iím sorry. I 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
axel@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
Received on Friday, 28 January 2011 09:16:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT