RE: Proposal for Paged Results

Jim,

To answer your first question. Nothing specifically limits this to SEARCH.
At the same time, the mechanism is still not baked enough that I think we
would gain much in working on generalizing it to other methods.

I'm not sure I understand your question about the Etag problem. The
collection itself has no etag. The tuple of the collection and the request
and the response is the thing that has an Etag.  In this context, it is
reasonable (even expected) that an Etag would be used to track changes of
this kind.

-----

"2. What does "most closely" mean here? "

Some ranges are not satisfiable. For example I ask for rows 1-50 but there
are only ten rows to give.

-----

">... normal SEARCH/PROPFIND result ... (with some XML element added to
>indicate the specific range in the response)

3. Perhaps this should be in the header not the body so that it could be
cached by a proxy.  While this is unlikely to make sense for a SEARCH, it
more plausible for a PROPFIND, if you accept my suggestion that paged
results makes sense for other DAV."

Good point, but this gets complicated (as in the case of byte ranges) we add
multiple ranges.

-----

">Example: Requesting further pages (but not caring if result set has
>changed):

4. I am a little worried by this example.  I think it unlikely that any
client would ever want to operate this way, as there would be no guarentee
that the client would get all the results.  Potentially new matching
records could be inserted at the server between the times the queries were
issued."

Yes. In this case the  the client shouldn't provide the Etag (even if the
server gave one).

-Saveen

Received on Tuesday, 15 September 1998 16:52:19 UTC