- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 1 Nov 2010 05:00:25 -0700
- 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 UTC