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

Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 1 Nov 2010 05:00:25 -0700
Message-ID: <AANLkTim4E8LyDEX8o+Pt8mGpLZOiNNuh2K5OMoVW7Jat@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: public-webapps@w3.org
On Mon, Nov 1, 2010 at 4:49 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>
>
> On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Mon, Nov 1, 2010 at 3:18 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> > On Mon, Nov 1, 2010 at 9:57 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> >>
>> >> On Mon, Nov 1, 2010 at 2:49 AM, Jeremy Orlow <jorlow@chromium.org>
>> >> wrote:
>> >> > On Mon, Nov 1, 2010 at 9:42 AM, Jonas Sicking <jonas@sicking.cc>
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Nov 1, 2010 at 1:46 AM, Jeremy Orlow <jorlow@chromium.org>
>> >> >> wrote:
>> >> >> > Actually, what's the use case for readyState?  I can't think of
>> >> >> > any
>> >> >> > uses
>> >> >> > that we'd want to encourage.  Maybe we should just remove it.
>> >> >>
>> >> >> The use-case that I've heard in similar situations goes something
>> >> >> like
>> >> >> this:
>> >> >>
>> >> >> Code makes a request and at some point later hands the request to
>> >> >> some
>> >> >> other piece of code which is interested in the result.
>> >> >> The other piece of code doesn't necessarily know if a result has
>> >> >> been
>> >> >> returned yet or not. Using readyState it can either simply get
>> >> >> .result,
>> >
>> > Actually, this isn't possible.  As first proposed by Ben in "Changes to
>> > IDBRequest and specification of the success and error events",
>> > IDBRequest.result was moved just to the success event.  So there is no
>> > way
>> > for something to access the result except through an onsuccess event
>> > handler.  So the only use case for readyState is figuring out if you
>> > need to
>> > re-issue a request.
>>
>> Good point, will have to think about that some more.
>>
>> >> or it can add a event listener for the "success" event and
>> >> >> wait for the event to fire.
>> >> >>
>> >> >> I think that makes sense here too.
>> >> >
>> >> > What about the cursor case though?  Given that we're re-using the
>> >> > same
>> >> > request object, I really don't think it makes much sense.
>> >>
>> >> It makes sense if the code the request is passed to is the one calling
>> >> continue(), no?
>> >
>> > What's the use case for this though?  It seems awfully odd that a cursor
>> > would be getting passed around after some async call after returning to
>> > the
>> > event loop.  If you haven't returned to the event loop since your last
>> > call,
>> > then there's no need to check ready state.  And things of course become
>> > very
>> > confusing if you're issued multiple calls.
>>
>> Consider code that performs some type of merge for example. Placing
>> several requests to different object stores and waiting for response
>> from all of them.
>
> So you're assuming that it'd set the same onsuccess handler for multiple
> cursors and then check the ready state of them all upon each call and only
> do processing when they're all ready?  If so, you can do this other ways
> (use a counter or wait until you've gotten a call from each event.source you
> expect), and this solution doesn't seem particularly more elegant to me.  If
> not, I don't understand this use case.

I don't really agree that a counter is more elegant. It's also more
complicated as you start iterating over the various cursors as you'll
then have to wait for a different number of cursors depending on the
values that you find.

> Either way, I'm pretty sure this isn't an example of "a cursor would be
> getting passed around after some async call after returning to the event
> loop" which I believe is the only use case where ready state would actually
> be necessary.

Why is it not? Calling .continue() on another cursor is async.

>> > Which brings up the point: what's the behavior if you call .continue()
>> > twice?  Will your on success fire twice?  What if the first result was
>> > null
>> > (because you're out of results).  Should onsuccess fire twice with nulls
>> > or
>> > only one null and ignore any subsequent continue() requests?
>>
>> I think that a call to .continue() on a cursor which still hasn't
>> returned a result from the last call to continue() should result in a
>> NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
>> two calls running at once, so I think the second call should either
>> throw or do nothing.
>
> Throw is much better than do nothing.  I think that's best for now, and we
> can spec the behavior in the future if there's demand.  I'll file a bug.

Thanks. I'll fix it as part of my current cursor-reworking patch.

> You didn't respond to "Btw, if we do keep readyState around, we should
> specify that its state changing should be done via the event loop to
> maintain run to completion semantics."  Would you agree?

I don't really agree. Run-to-completion doesn't state that properties
can't change during the execution of a specific thread. It states that
properties shouldn't change in response to background threads and the
like. Compare to XMLHttpRequest.readyState which changes synchronously
in response to a call .open().

Or simply compare to window.foo = "bar";

/ Jonas
Received on Monday, 1 November 2010 12:01:24 GMT

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