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

On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> What's the current thinking in terms of events that we're firing?  I
> remember we talked about this a bit, but I don't remember the conclusion and
> I can't find it captured anywhere.
> Here's a brain dump of the requirements as I remember them:
> * Everything should have a source attribute.
> * Everything done in the context of a transaction should have a transaction
> attribute.  (Probably even errors, which I believe is not the current case.)
> * Only success events should have a result.
> * Only error events should have a code and a message....or should they just
> have an error attribute which holds an IDBDatabaseError object?  (If it's
> the former, then do we even need an interface for IDBDatabaseError to be
> defined?)
> * IIRC, Jonas suggested at some point that maybe there should be additional
> attributes beyond just the source and/or objects should link to their
> parents.  (The latter probably makes the most sense, right?  If so, I'll bug
> it.)
> Is there anything I'm missing?
> As far as I can tell, this means we need 5 events: an IDBEvent (with source)
> and then error with transaction, error without, success with, and success
> without.  That seems kind of ugly though.
> Another possibility is that we could put a transaction attribute on IDBEvent
> that's null when there's no transaction.  And then error and success would
> have their own subclasses.  To me, this sounds best.
> Thoughts?

Actually, I was proposing something entirely different.

IDBRequest should look like this:

interface IDBRequest : EventTarget {
    attribute any result;
    attribute unsigned long errorCode;
    attribute DOMObject source;
    attribute IDBTransaction transaction;

    const unsigned short LOADING = 1;
    const unsigned short DONE = 2;
    readonly attribute unsigned short readyState;

             attribute Function       onsuccess;
             attribute Function       onerror;
};

"success" and "error" events are plain Event objects, i.e. no
indexedDB-specific properties.

The advantage of this is:
1. Request objects are actually useful as representing the request.
Consumers of a request can check what the readystate is and either get
the .result or attach a event listener as appropriate. (As things
stand now you can't really rely on .readyState. The only thing it
tells you is if you got to the request too late or not. If you risk
getting there too late you better rewrite your code)
2. Easier to implement a promises-style API on top of indexedDB.
3. More similar to for example XMLHttpRequest

The downside is:
1. Have to use a bigger syntax to get to the result. "event.result"
vs. "event.target.result".

/ Jonas

Received on Friday, 28 January 2011 01:15:20 UTC