W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [IndexedDB] Events and requests

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 10 Dec 2010 12:47:38 -0800
Message-ID: <AANLkTi=6y-vQkWNDsmt3Cr1OVB+J6BBNAMOgbWoVNJ62@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Webapps WG <public-webapps@w3.org>
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 Friday, 10 December 2010 20:48:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT