W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 4 Nov 2010 15:47:25 +0100
Message-ID: <AANLkTin67cM=3Z2koc2EUigMLtw2zaLHW--apt5nJt5y@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT