Protocol support for maintaining a "local file area" on the clien t

I've been reviewing the protocol wrt client maintenance of a
"local file area" (i.e. a tree of files on the client that
reflect the state on the server).  I identified two issues:

The first issue was with the extended UPDATE semantics
for the baseline feature (this is what lets you update all
the members of a baseline-controlled collection with a new
baseline).  In order for a client file area to efficiently
reflect the state on the server, it needs to have the UPDATE
request return the set of affected resources, just as a
MERGE request does.

This is pretty easy to fix ... just add a DAV:updated-set
and DAV:ignored-set in the UPDATE response body.

The second issue was having multiple file areas for the same
workspace.  To handle this efficiently, we could allow one
workspace to be UPDATE'd by another.  This allows a client to
create a separate workspace for its file area, and then use
UPDATE to determine how that file area should be changed to
reflect the changes made to some shared workspace.

JimW: Note that this also makes your "initialize a new workspace"
scenario much simpler ... you just use one UPDATE call
instead of a series of VERSION-CONTROL calls.

Any objections?  If not, I will plan on requesting these
extensions to UPDATE semantics during the "IESG last call"
period.

Cheers,
Geoff

Received on Friday, 27 April 2001 08:55:52 UTC