Re: [Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior

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.


> >  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?
>

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.

J