- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 1 Nov 2010 04:08:09 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-webapps@w3.org
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. > 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. > P.S. I'm happy to discuss all of this f2f tomorrow rather than over email > now. Speaking of which, would be great to have an agenda. Some of the bigger items are: * Dynamic transactions * Arrays-as-keys * Arrays and indexes (what to do if the keyPath for an index evaluates to an array) * Synchronous API / Jonas
Received on Monday, 1 November 2010 11:09:04 UTC