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: Jeremy Orlow <jorlow@chromium.org>
Date: Mon, 1 Nov 2010 10:18:52 +0000
Message-ID: <AANLkTi=rYqxHQ6LYctJEm=fRP0aVs5NELgceCRhZO_H9@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps@w3.org
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.


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

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?

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.

J

P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
now.
Received on Monday, 1 November 2010 10:19:43 GMT

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