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

On Thu, Jan 27, 2011 at 5:48 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jan 27, 2011 at 5:30 PM, Axel Rauschmayer <axel@rauschma.de>
> wrote:
> > I am really sorry to bring this up again, but: Why not separate concerns?
> Why not separate input data and output data?
> >
> > If onsuccess and onerror were handed in as an input parameters, would
> there be any need for readyState, LOADING, and DONE?
>
> We decided a long long time ago, based on input from web developers,
> to use DOM-Events as notification mechanism. We went through the same
> thing in the FileReader API where I initially suggested using a
> different type of callback, but got the feedback that developers
> preferred to use DOM-Events.
>
> 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.
>

I'm still not convinced this use case is necessary either, but we've already
argued that to death, so let's not start up again.

Is all of this what was implemented in FF4b9?  If so, I'll do it in
Chromium, though the event.target syntax really is kind of horrible.

Lastly, let's say you're doing cursor.continue() on an index cursor, how can
you get a handle to the objectStore?  I believe you can't.  Should we add in
something for that?  (Most likely give the index a link to its object store?
 And maybe even give a cursor a link back up as well?)

J


> > 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?
>
> / Jonas
>