Re: [IndexedDB] Events and requests

Promises/futures would be great, yes! Cleaner than the current solution. They are the right metaphor for this kind of thing.

http://en.wikipedia.org/wiki/Futures_and_promises

On Jan 10, 2011, at 22:31 , Jonas Sicking wrote:

> 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
>>>> 
>>> 
>>> 
>> 
> 
> 

-- 
Dr. Axel Rauschmayer
Axel.Rauschmayer@ifi.lmu.de
http://hypergraphs.de/
### Hyena: organize your ideas, free at hypergraphs.de/hyena/

Received on Monday, 10 January 2011 21:57:00 UTC