Re: [IndexedDB] Events and requests

FWIW Jonas' proposed changes have been implemented and will be
included in Firefox 4 Beta 9, due out in a few days.

-Ben

On Fri, Dec 10, 2010 at 12:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> I've been reaching out to get feedback, but no success yet. Will re-poke.
>
> / Jonas
>
> On Fri, Dec 10, 2010 at 4:33 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> 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
>>
>
>

Received on Monday, 10 January 2011 16:22:40 UTC