W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1998

Proposal for Paged Results

From: Saveen Reddy (Exchange) <saveenr@Exchange.Microsoft.com>
Date: Fri, 4 Sep 1998 12:20:11 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010B0CDD52@DINO>
To: www-webdav-dasl@w3.org
Below is a sketch of adding paged results to DASL. Dale and I developed this
from Dale's initial proposal ...

-Saveen

-----------

DASL PAGED RESULTS 

Motivation

Simple queries ("list all files in folder") can have large result sets. A
client looking at such a list literally browses through "pages" of the
result set. That is, clients only show specific sections of the result set
to the user and thus only need to download specific those specific sections.
This allows for less resource usage and because of that mroe responsive UI.

Drawbacks

Server & clients need to be more complex, but only in cases when they really
need this fe`ature. The normal search case is not affected.

Additions to DASL

On top of what DASL already defines, doing paged results will require a way
to indicate what page to retrieve in a search request. In this proposal it
is the Range header.

Example: Requesting a page of a search:

-The client constructs a complete SEARCH request
-The client adds a Range header to identify the page of interest
-The client sends the Request
-The server constructs the set of records that most closely match the
requested Page
-The server MAY provide an ETag for this response caching the result set
-The server adds XML elements in the PROPFIND response that identifies the
specific range returned
-The server adds XML elements in the PROPFIND response that tells what the
size of the result set
- the server sends the response

>> Request

SEARCH /container/ HTTP/1.1
Range: rows=10-20
Content-Type: text/xml
Content-Length: xxx

... insert query here ...

>> Response

HTTP/1.1 207 Multistatus
Content-Type: text/xml
Content-Length: xxx
E-Tag: qqqqqq

... normal SEARCH/PROPFIND result ... (with some XML element added to
indicate the specific range in the response)
	
Example: Requesting further pages of same result:

-Client constructs the same original Query
-Client adds if-Match: with an etag

>> Request

SEARCH /container/ HTTP/1.1
Range: rows=20-30
If-Match: qqqqqq
Content-Type: text/xml
Content-Length: xxx

... insert query here ...

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

-Client constructs the same original Query
-Client does not use if-Match header

>> Request

SEARCH /container/ HTTP/1.1
Range: rows=20-30
Content-Type: text/xml
Content-Length: xxx

... insert query here ...



The Range header

Today the Range header supports a list of byte ranges.

For paged results, need to define additional support for "rows" 

Examples:

Range: rows=1-20
Range: rows=1-end

Currently, only concerned about a single range at a time, not multiple
ranges

QSD
Will potentially need QSD support, for ranges (for example, only some
properties may be allowed in a sort specification whe paged results are
being used) that is to be defined later.
 
Received on Friday, 4 September 1998 15:19:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT