- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 4 Nov 2010 15:47:25 +0100
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
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. > Are we reasonably sure that LOADING and DONE are all we need? 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 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? / Jonas
Received on Thursday, 4 November 2010 14:48:19 UTC