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