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.mozi...@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 <jo...@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 <jor...@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 <jor...@chromium.org> wrote: >>>>> >>>>> On Tue, Nov 9, 2010 at 11:35 AM, Jonas Sicking <jo...@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.rauschma...@ifi.lmu.de http://hypergraphs.de/ ### Hyena: organize your ideas, free at hypergraphs.de/hyena/
