Re: [IndexedDB] Events and requests

Any additional thoughts on this?  If no one else cares, then we can go with
Jonas' proposal (and we should file a bug).

J

On Thu, Nov 11, 2010 at 12:06 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Tue, Nov 9, 2010 at 11:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> Hi All,
>>
>> One of the things we briefly discussed at the summit was that we
>> should make IDBErrorEvents have a .transaction. This since we are
>> allowing you to place new requests from within error handlers, but we
>> currently provide no way to get from an error handler to any useful
>> objects. Instead developers will have to use closures to get to the
>> transaction or other object stores.
>>
>> Another thing that is somewhat strange is that we only make the result
>> available through the success event. There is no way after that to get
>> it from the request. So instead we use special event interfaces with
>> supply access to source, transaction and result.
>>
>> Compare this to how XMLHttpRequests work. Here the result and error
>> code is available on the request object itself. The 'load' event,
>> which is equivalent to our 'success' event didn't supply any
>> information until we recently added progress event support. But still
>> it only supplies information about the progress, not the actual value
>> itself.
>>
>> One thing we could do is to move
>>
>> .source
>> .transaction
>> .result
>> .error
>>
>> to IDBRequest. Then make "success" and "error" events be simple events
>> which only implement the Event interface. I.e. we could get rid of the
>> IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
>> interfaces.
>>
>> We'd still have to keep IDBVersionChangeEvent, but it can inherit
>> Event directly.
>>
>> The request created from IDBFactory.open would return a IDBRequest
>> where .transaction and .source is null. We already fire a IDBEvent
>> where .source is null (actually, the spec currently doesn't define
>> what the source should be I see now).
>>
>>
>> The only major downside with this setup that I can see is that the
>> current syntax:
>>
>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>> function(e) {
>>  alert(e.result);
>> }
>>
>> would turn into the slightly more verbose
>>
>> db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess =
>> function(e) {
>>  alert(e.target.result);
>> }
>>
>> (And note that with the error handling that we have discussed, the
>> above code snippets are actually plausible (apart from the alert() of
>> course)).
>>
>> The upside that I can see is that we behave more like XMLHttpRequest.
>> It seems that people currently follow a coding pattern where they
>> place a request and at some later point hand the request to another
>> piece of code. At that point the code can either get the result from
>> the .result property, or install a onload handler and wait for the
>> result if it isn't yet available.
>>
>> However I only have anecdotal evidence that this is a common coding
>> pattern, so not much to go on.
>>
>
> Here's a counter proposal:  Let's add .transaction, .source, and .result to
> IDBEvent and just specify them to be null when there is no transaction,
> source, and/or result.  We then remove readyState from IDBResult as it
> serves no purpose.
>
> What I'm proposing would result in an API that's much more similar to what
> we have at the moment, but would be a bit different than XHR.  It is
> definitely good to have similar patterns for developers to follow, but I
> feel as thought the model of IndexedDB is already pretty different from XHR.
>  For example, method calls are supplied parameters and return an IDBRequest
> object vs you using new to create the XHR object and then making method
> calls to set it up and then making a method call to start it.  In fact, if
> you think about it, there's really not that much XHR and IndexedDB have in
> common except that they use event handlers.
>
> As for your proposal, let me think about it for a bit and forward it on to
> some people I know who are playing with IndexedDB already.
>
> J
>