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

"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