- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 4 Nov 2010 18:07:31 +0100
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
On Thu, Nov 4, 2010 at 4:03 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Nov 4, 2010 at 3:47 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Thu, Nov 4, 2010 at 3:36 PM, Jeremy Orlow <jorlow@chromium.org> wrote: >> > On Thu, Nov 4, 2010 at 12:35 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> >> >> On Mon, Nov 1, 2010 at 3:17 PM, Shawn Wilsher <sdwilsh@mozilla.com> >> >> wrote: >> >> > On 11/1/2010 5:29 AM, Jeremy Orlow wrote: >> >> >> >> >> >> If not, I think we should avoid adding surface area for something >> >> >> we >> >> >> don't >> >> >> really understand very well. >> >> > >> >> > I agree with this. Less is better at this point I think (when >> >> > appropriate, >> >> > of course). >> >> >> >> Of course, the question is where it's appropriate. >> >> >> >> The reason I prefer to keep readyState is that I've seen things move >> >> that way elsewhere. We've recently added it to Document, >> >> HTMLMediaElement, EventSource and WebSocket. >> > >> > In any of those examples, can the ready state ever reset from its done >> > position to one of the earlier states? Since we're saying that calling >> > IDBCursor.continue() while there's already a continue pending is not >> > allowed, I'm not as worried about this as I was, but if none of the >> > others >> > are, readyState might at the very least be the wrong name to use. >> >> For XMLHttpRequest, Document and HTMLMediaElement the readyState can >> go back to previous states. >> >> > Also, do any of those examples have just 2 states? >> >> No. >> >> > I find it a bit odd that >> > IDBRequest.readyState is currently little more than "would >> > IDBRequest.result >> > be valid (if the attribute existed)". We of course can't just have the >> > attribute be null/undefined to signal such states (since they're >> > cloneable >> > values and thus could be themselves the result). >> >> That doesn't allow differenting "there was an error and thus no >> result" from "still running the request, so no result yet". >> >> > Throwing would be one option, but isn't a great one. >> >> Agree, forcing people to catch exceptions to check for a >> state/condition isn't good. >> >> > And what happens if we need to add states in the future? Is there any >> > past >> > experience with this? It seems like it could be tough if not >> > impossible. > > What about this? It seems as though once people depend on readyState, it > can't be changed. Which would be a reason to hold off until we better > understand the use cases we'd solve with it. Again, I struggle to think of what ready-states we would be adding in the future. I agree that future changes to API is something we should always keep in mind, but in this case it seems unlikely to me that 'll need to make changes. And we can never be 100% certain that we won't need to make changes in the future. >> > Are we reasonably sure that LOADING and DONE are all we need? Yes. >> > At the very >> > least, maybe we need a third state for the cursor case to say that >> > there's >> > currently a result, but you're not at the end of the cursor yet (and >> > thus >> > DONE would never transition to another state). I'm not sure I understand this statement. Here is how things work currently when iterating a objectStore with one entry: req = objectStore.openCursor(null, NEXT); // req.readyState == LOADING <wait for success event> c = event.result; // c == IDBCursor // c.value == value of objectStore entry // req.readyState == DONE c.continue(); // req.readyState == LOADING <wait for success event> c = event.result; // c == null // req.readyState == DONE So each iteration in the cursor is treated as a separate request, with the exception that it reuses the same request object. If we were to put the result on the request object, you can already tell "readyState == DONE because we moved to the next record" from "readyState == DONE because we ran out of records". >> I don't know what state that would be. And would those states be added >> while keeping the rest of the API be similar enough that we wouldn't >> be going down a different code path anyway? > > If we don't have another state, how would you differentiate between > IDBRequest.result's null/undefined meaning the value null/undefined and the > cursor being at the end? It seems unavoidable. The result of cursor navigation is the cursor object itself if a entry was found, and null if the end was reached. This is already in spec. So it's no problem telling them apart. / Jonas
Received on Thursday, 4 November 2010 17:08:21 UTC