Re: Proposal for Paged Results

At 12:20 PM 9/4/98 PDT, Saveen Reddy (Exchange) wrote:
>Below is a sketch of adding paged results to DASL. Dale and I developed this
>from Dale's initial proposal ...

This is a good step.  I have one global question and some smaller ones.

1. Should this be proposed for use in DAV as a whole, not just DASL?  The
functionality would seem just as useful in retrieving a large PROPFIND and
a large SEARCH.  And what about HTTP?  Once you define the rows production
in the Range header, are there other HTTP methods (or resources) for which
it might make sense?

The only thing that worries me about this suggestion is that I don't think
the Etag would be useful in doing paged results on a PROPFIND, because the
Etag of a collection would not necessarily change if one did a PROPPATCH on
one of the collections' members.

Local questions:

>-The server constructs the set of records that most closely match the
>requested Page

2. What does "most closely" mean here? 

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

In any case, you need to provide these details to make the proposal complete.

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

I suggest the example be dropped from the protocol.  We should not include
examples of poor software practises.

regards

Jim

Received on Monday, 14 September 1998 12:50:19 UTC