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

Also, do any of those examples have just 2 states?  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).  Throwing would be one
option, but isn't a great one.

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).

J