- From: ben turner <bent.mozilla@gmail.com>
- Date: Mon, 10 Jan 2011 08:13:49 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Webapps WG <public-webapps@w3.org>
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