- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 27 Apr 2001 08:58:03 -0400
- To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
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