- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 27 Apr 2001 16:06:46 +0100
- To: ietf-dav-versioning@w3.org
"Clemm, Geoff" <gclemm@rational.com> wrote: > 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. That's easy enough, no objections here. > The second issue was having multiple file areas for the same > workspace. What is a 'file area'? > 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. Sounds similar to the operations currently available under baseline -- but I'll wait to hear what a file area is first. > Any objections? If not, I will plan on requesting these > extensions to UPDATE semantics during the "IESG last call" > period. Tim
Received on Friday, 27 April 2001 11:08:22 UTC