[Standards-JIG] JEP-0059: Result Set Manipulation

Andrew Plotkin erkyrath at eblong.com
Thu Jan 19 04:16:09 UTC 2006

Having not looked at JEPs recently, I dive back into the stack of 

The theory is to "Page through a result set by retrieving the items in 
smaller subsets." However, the proposed mechanism is hard to use. If I 
start fetching pages of a result set, I have no way to tell if the result 
set changes out from under me. (Say, if the underlying results change 
between the time I fetch page 2 and page 3.) Depending on the server's 
ordering, I may miss some results, see others twice, or both.

The usual fix for this sort of thing is to include an identifier in the 
server's result. This stays the same for as long as the server's 
underlying data stays the same. (It could be a timestamp of the most 
recent data change, or just an incrementing integer.) Each time the client 
fetches a page (after the first), it can compare the identifier with the 
one from the previous page. If they don't match, the client can either 
declare the paged-get to be a failure or start over, whichever it likes.

(Of course, if the client starts over, but the server's data is churning 
continuously, the client might *keep* starting over. And never 
actually finish fetching pages, I mean. I don't see any way around that; 
the client just has to be written to give up after three restarts or some 
such heuristic.)

I guess it's valuable to have this identifier in <count> requests also.

Also, typo: the line before example 8 is:

> The responding entity then returns the first page of the result set:

...which should say "second page".


"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the
President does it then it's legal") is contemptible.

More information about the Standards mailing list