Re: [IndexedDB] Events and requests

I did some outreach to developers and while I didn't get a lot of
feedback, what I got was positive to this change.

The basic use-case that was brought up was implementing a promises
which, as I understand it, works similar to the request model I'm
proposing. I.e. you build up these "promise" objects which represent a
result which may or may not have arrived yet. At some point you can
either read the value out, or if it hasn't arrived yet, register a
callback for when the value arrives.

It was pointed out that this is still possible with how the spec is
now, but it will probably result in that developers will come up with
conventions to set the result on the request themselves. This wouldn't
be terribly bad, but also seems nice if we can help them.

/ Jonas

On Mon, Jan 10, 2011 at 8:13 AM, ben turner <bent.mozilla@gmail.com> wrote:
> 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 21:32:27 UTC