"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