Discussion:
[Bug 10430] New: [IndexedDB] We need to make it more clear IDBRequests can be reused and spec readyState's behavior
(too old to reply)
Jeremy Orlow
2010-11-01 08:46:18 UTC
Permalink
Actually, what's the use case for readyState? I can't think of any uses
that we'd want to encourage. Maybe we should just remove it.

J
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430
Summary: [IndexedDB] We need to make it more clear IDBRequests
can be reused and spec readyState's behavior
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest right now clearly
assumes
IDBRequests are only going to be used once. But IDBCursor.continue()
reuses
them. At the very least, we'll need to clean up the .readyState section to
make it clear it's possible to go from DONE to LOADING (or we can remove it
altogether?). I think some notes explicitly pointing out that some parts
of
the API reuse them would be helpful as well.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Jonas Sicking
2010-11-01 09:42:39 UTC
Permalink
Actually, what's the use case for readyState?  I can't think of any uses
that we'd want to encourage.  Maybe we should just remove it.
The use-case that I've heard in similar situations goes something like this:

Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result, or it can add a event listener for the "success" event and
wait for the event to fire.

I think that makes sense here too.

/ Jonas
Jeremy Orlow
2010-11-01 09:49:55 UTC
Permalink
Post by Jonas Sicking
Post by Jeremy Orlow
Actually, what's the use case for readyState? I can't think of any uses
that we'd want to encourage. Maybe we should just remove it.
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result, or it can add a event listener for the "success" event and
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though? Given that we're re-using the same
request object, I really don't think it makes much sense.

J
Jonas Sicking
2010-11-01 09:57:27 UTC
Permalink
Post by Jonas Sicking
Actually, what's the use case for readyState?  I can't think of any uses
that we'd want to encourage.  Maybe we should just remove it.
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result, or it can add a event listener for the "success" event and
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though?  Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one calling
continue(), no?

/ Jonas
Jeremy Orlow
2010-11-01 10:18:52 UTC
Permalink
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Actually, what's the use case for readyState? I can't think of any
uses
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
that we'd want to encourage. Maybe we should just remove it.
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result,
Actually, this isn't possible. As first proposed by Ben in "Changes to
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event. So there is no way
for something to access the result except through an onsuccess event
handler. So the only use case for readyState is figuring out if you need to
re-issue a request.
Post by Jonas Sicking
or it can add a event listener for the "success" event and
Post by Jeremy Orlow
Post by Jonas Sicking
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though? Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one calling
continue(), no?
What's the use case for this though? It seems awfully odd that a cursor
would be getting passed around after some async call after returning to the
event loop. If you haven't returned to the event loop since your last call,
then there's no need to check ready state. And things of course become very
confusing if you're issued multiple calls.

Which brings up the point: what's the behavior if you call .continue()
twice? Will your on success fire twice? What if the first result was null
(because you're out of results). Should onsuccess fire twice with nulls or
only one null and ignore any subsequent continue() requests?

Btw, if we do keep readyState around, we should specify that its state
changing should be done via the event loop to maintain run to completion
semantics.

J

P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
now.
Jonas Sicking
2010-11-01 11:08:09 UTC
Permalink
Post by Jonas Sicking
Post by Jonas Sicking
Actually, what's the use case for readyState?  I can't think of any uses
that we'd want to encourage.  Maybe we should just remove it.
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result,
Actually, this isn't possible.  As first proposed by Ben in "Changes to
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event.  So there is no way
for something to access the result except through an onsuccess event
handler.  So the only use case for readyState is figuring out if you need to
re-issue a request.
Good point, will have to think about that some more.
Post by Jonas Sicking
or it can add a event listener for the "success" event and
Post by Jonas Sicking
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though?  Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one calling
continue(), no?
What's the use case for this though?  It seems awfully odd that a cursor
would be getting passed around after some async call after returning to the
event loop.  If you haven't returned to the event loop since your last call,
then there's no need to check ready state.  And things of course become very
confusing if you're issued multiple calls.
Consider code that performs some type of merge for example. Placing
several requests to different object stores and waiting for response
from all of them.
Which brings up the point: what's the behavior if you call .continue()
twice?  Will your on success fire twice?  What if the first result was null
(because you're out of results).  Should onsuccess fire twice with nulls or
only one null and ignore any subsequent continue() requests?
I think that a call to .continue() on a cursor which still hasn't
returned a result from the last call to continue() should result in a
NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
two calls running at once, so I think the second call should either
throw or do nothing.
P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
now.
Speaking of which, would be great to have an agenda. Some of the
bigger items are:

* Dynamic transactions
* Arrays-as-keys
* Arrays and indexes (what to do if the keyPath for an index evaluates
to an array)
* Synchronous API

/ Jonas
Jeremy Orlow
2010-11-01 11:49:00 UTC
Permalink
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Actually, what's the use case for readyState? I can't think of any uses
that we'd want to encourage. Maybe we should just remove it.
The use-case that I've heard in similar situations goes something
like
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Code makes a request and at some point later hands the request to
some
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result,
Actually, this isn't possible. As first proposed by Ben in "Changes to
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event. So there is no
way
Post by Jeremy Orlow
for something to access the result except through an onsuccess event
handler. So the only use case for readyState is figuring out if you need
to
Post by Jeremy Orlow
re-issue a request.
Good point, will have to think about that some more.
Post by Jeremy Orlow
Post by Jonas Sicking
or it can add a event listener for the "success" event and
Post by Jeremy Orlow
Post by Jonas Sicking
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though? Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one calling
continue(), no?
What's the use case for this though? It seems awfully odd that a cursor
would be getting passed around after some async call after returning to
the
Post by Jeremy Orlow
event loop. If you haven't returned to the event loop since your last
call,
Post by Jeremy Orlow
then there's no need to check ready state. And things of course become
very
Post by Jeremy Orlow
confusing if you're issued multiple calls.
Consider code that performs some type of merge for example. Placing
several requests to different object stores and waiting for response
from all of them.
So you're assuming that it'd set the same onsuccess handler for multiple
cursors and then check the ready state of them all upon each call and only
do processing when they're all ready? If so, you can do this other ways
(use a counter or wait until you've gotten a call from each event.source you
expect), and this solution doesn't seem particularly more elegant to me. If
not, I don't understand this use case.

Either way, I'm pretty sure this isn't an example of "a cursor would be
getting passed around after some async call after returning to the event
loop" which I believe is the only use case where ready state would actually
be necessary.
Post by Jonas Sicking
Post by Jeremy Orlow
Which brings up the point: what's the behavior if you call .continue()
twice? Will your on success fire twice? What if the first result was
null
Post by Jeremy Orlow
(because you're out of results). Should onsuccess fire twice with nulls
or
Post by Jeremy Orlow
only one null and ignore any subsequent continue() requests?
I think that a call to .continue() on a cursor which still hasn't
returned a result from the last call to continue() should result in a
NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
two calls running at once, so I think the second call should either
throw or do nothing.
Throw is much better than do nothing. I think that's best for now, and we
can spec the behavior in the future if there's demand. I'll file a bug.

You didn't respond to "Btw, if we do keep readyState around, we should
specify that its state changing should be done via the event loop to
maintain run to completion semantics." Would you agree?
Post by Jonas Sicking
P.S. I'm happy to discuss all of this f2f tomorrow rather than over email
Post by Jeremy Orlow
now.
Speaking of which, would be great to have an agenda. Some of the
* Dynamic transactions
* Arrays-as-keys
* Arrays and indexes (what to do if the keyPath for an index evaluates
to an array)
* Synchronous API
I forked this into another thread. Let's discuss there please.

J
Jonas Sicking
2010-11-01 12:00:25 UTC
Permalink
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jonas Sicking
Post by Jonas Sicking
Actually, what's the use case for readyState?  I can't think of
any
uses
that we'd want to encourage.  Maybe we should just remove it.
The use-case that I've heard in similar situations goes something
like
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result,
Actually, this isn't possible.  As first proposed by Ben in "Changes to
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event.  So there is no way
for something to access the result except through an onsuccess event
handler.  So the only use case for readyState is figuring out if you need to
re-issue a request.
Good point, will have to think about that some more.
Post by Jonas Sicking
or it can add a event listener for the "success" event and
Post by Jonas Sicking
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though?  Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one calling
continue(), no?
What's the use case for this though?  It seems awfully odd that a cursor
would be getting passed around after some async call after returning to the
event loop.  If you haven't returned to the event loop since your last call,
then there's no need to check ready state.  And things of course become very
confusing if you're issued multiple calls.
Consider code that performs some type of merge for example. Placing
several requests to different object stores and waiting for response
from all of them.
So you're assuming that it'd set the same onsuccess handler for multiple
cursors and then check the ready state of them all upon each call and only
do processing when they're all ready?  If so, you can do this other ways
(use a counter or wait until you've gotten a call from each event.source you
expect), and this solution doesn't seem particularly more elegant to me.  If
not, I don't understand this use case.
I don't really agree that a counter is more elegant. It's also more
complicated as you start iterating over the various cursors as you'll
then have to wait for a different number of cursors depending on the
values that you find.
Post by Jeremy Orlow
Either way, I'm pretty sure this isn't an example of "a cursor would be
getting passed around after some async call after returning to the event
loop" which I believe is the only use case where ready state would actually
be necessary.
Why is it not? Calling .continue() on another cursor is async.
Post by Jeremy Orlow
Post by Jonas Sicking
Which brings up the point: what's the behavior if you call .continue()
twice?  Will your on success fire twice?  What if the first result was null
(because you're out of results).  Should onsuccess fire twice with nulls or
only one null and ignore any subsequent continue() requests?
I think that a call to .continue() on a cursor which still hasn't
returned a result from the last call to continue() should result in a
NOT_ALLOWED_ERR being thrown. There is just no logical way to honor
two calls running at once, so I think the second call should either
throw or do nothing.
Throw is much better than do nothing.  I think that's best for now, and we
can spec the behavior in the future if there's demand.  I'll file a bug.
Thanks. I'll fix it as part of my current cursor-reworking patch.
Post by Jeremy Orlow
You didn't respond to "Btw, if we do keep readyState around, we should
specify that its state changing should be done via the event loop to
maintain run to completion semantics."  Would you agree?
I don't really agree. Run-to-completion doesn't state that properties
can't change during the execution of a specific thread. It states that
properties shouldn't change in response to background threads and the
like. Compare to XMLHttpRequest.readyState which changes synchronously
in response to a call .open().

Or simply compare to window.foo = "bar";

/ Jonas
Jeremy Orlow
2010-11-01 12:29:05 UTC
Permalink
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Actually, what's the use case for readyState? I can't think of any
uses
that we'd want to encourage. Maybe we should just remove it.
The use-case that I've heard in similar situations goes something
like
Code makes a request and at some point later hands the request to some
other piece of code which is interested in the result.
The other piece of code doesn't necessarily know if a result has been
returned yet or not. Using readyState it can either simply get
.result,
Actually, this isn't possible. As first proposed by Ben in "Changes
to
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
IDBRequest and specification of the success and error events",
IDBRequest.result was moved just to the success event. So there is no way
for something to access the result except through an onsuccess event
handler. So the only use case for readyState is figuring out if you need to
re-issue a request.
Good point, will have to think about that some more.
Post by Jeremy Orlow
Post by Jonas Sicking
or it can add a event listener for the "success" event and
Post by Jeremy Orlow
Post by Jonas Sicking
wait for the event to fire.
I think that makes sense here too.
What about the cursor case though? Given that we're re-using the same
request object, I really don't think it makes much sense.
It makes sense if the code the request is passed to is the one
calling
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
continue(), no?
What's the use case for this though? It seems awfully odd that a
cursor
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
would be getting passed around after some async call after returning
to
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
the
event loop. If you haven't returned to the event loop since your last call,
then there's no need to check ready state. And things of course
become
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Jeremy Orlow
very
confusing if you're issued multiple calls.
Consider code that performs some type of merge for example. Placing
several requests to different object stores and waiting for response
from all of them.
So you're assuming that it'd set the same onsuccess handler for multiple
cursors and then check the ready state of them all upon each call and
only
Post by Jeremy Orlow
do processing when they're all ready? If so, you can do this other ways
(use a counter or wait until you've gotten a call from each event.source
you
Post by Jeremy Orlow
expect), and this solution doesn't seem particularly more elegant to me.
If
Post by Jeremy Orlow
not, I don't understand this use case.
I don't really agree that a counter is more elegant.
I said "doesn't seem particularly more elegant to me". In other words, I
don't think it's enough more elegant that it's worth the additional API
surface area.
Post by Jonas Sicking
It's also more
complicated as you start iterating over the various cursors as you'll
then have to wait for a different number of cursors depending on the
values that you find.
I'm not really following you. I guess in SQL terms you're talking about
left/outter joins?
Post by Jonas Sicking
Post by Jeremy Orlow
Either way, I'm pretty sure this isn't an example of "a cursor would be
getting passed around after some async call after returning to the event
loop" which I believe is the only use case where ready state would
actually
Post by Jeremy Orlow
be necessary.
Why is it not? Calling .continue() on another cursor is async.
I said "be necessary". I'm pretty sure code composability _after returning
to the event loop_ is the only use case where a readyState would be
_necessary_. I'd love to hear a concrete example of why someone might need
to do this.

As for it being convenient, I don't think think your example is that much
more convenient than other possible ways of doing it. Have any developers
actually done something like this and found it painful? Is there any code
you can point us to that would make the scenario more concrete and clear?
If not, I think we should avoid adding surface area for something we don't
really understand very well.

J
Shawn Wilsher
2010-11-01 14:17:24 UTC
Permalink
Post by Jeremy Orlow
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).

Cheers,

Shawn
Jonas Sicking
2010-11-04 11:35:06 UTC
Permalink
 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.

I do agree that as long as the result isn't on IDBRequest then it
doesn't make much sense since if you get a reference to a IDBRequest
with readyState=DONE you can't get to the result anyway.

/ Jonas
Jeremy Orlow
2010-11-04 14:36:05 UTC
Permalink
Post by Shawn Wilsher
Post by Shawn Wilsher
Post by Jeremy Orlow
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,
Post by Shawn Wilsher
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
Jonas Sicking
2010-11-04 14:47:25 UTC
Permalink
Post by Jeremy Orlow
Post by Jonas Sicking
 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.
Post by Jeremy Orlow
Also, do any of those examples have just 2 states?
No.
Post by Jeremy Orlow
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".
Post by Jeremy Orlow
 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.
Post by Jeremy Orlow
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
Jeremy Orlow
2010-11-04 15:03:31 UTC
Permalink
Post by Jeremy Orlow
Post by Jeremy Orlow
Post by Jonas Sicking
Post by Shawn Wilsher
Post by Jeremy Orlow
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
Post by Jeremy Orlow
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.
Post by Jeremy Orlow
Also, do any of those examples have just 2 states?
No.
Post by Jeremy Orlow
I find it a bit odd that
IDBRequest.readyState is currently little more than "would
IDBRequest.result
Post by Jeremy Orlow
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
Post by Jeremy Orlow
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".
Post by Jeremy Orlow
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.
Post by Jeremy Orlow
And what happens if we need to add states in the future? Is there any
past
Post by Jeremy Orlow
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.
Post by Jeremy Orlow
Post by Jeremy Orlow
Are we reasonably sure that LOADING and DONE are all we need? At the
very
Post by Jeremy Orlow
least, maybe we need a third state for the cursor case to say that
there's
Post by Jeremy Orlow
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
Jonas Sicking
2010-11-04 17:07:31 UTC
Permalink
Post by Jonas Sicking
Post by Jeremy Orlow
Post by Jonas Sicking
 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.
Post by Jeremy Orlow
Also, do any of those examples have just 2 states?
No.
Post by Jeremy Orlow
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".
Post by Jeremy Orlow
 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.
Post by Jeremy Orlow
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.
Post by Jonas Sicking
Post by Jeremy Orlow
 Are we reasonably sure that LOADING and DONE are all we need?
Yes.
Post by Jonas Sicking
Post by Jeremy Orlow
 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".
Post by Jonas Sicking
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
Ian Hickson
2010-11-04 18:03:01 UTC
Permalink
Post by Jeremy Orlow
Also, do any of those examples have just 2 states?
No.
Early drafts of several of them just had two states, actually, but in each
case we ended up adding more later.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
bugzilla-OlaYgOEDUgM+XRW/
2010-11-08 11:34:58 UTC
Permalink
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10430

Jonas Sicking <jonas-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

--- Comment #3 from Jonas Sicking <jonas-***@public.gmane.org> 2010-11-08 11:34:58 UTC ---
Should be fixed by http://dvcs.w3.org/hg/IndexedDB/rev/8716288a4fe1

Would be great if someone could check that it looks correct.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Loading...