W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

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

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 27 Apr 2001 16:06:46 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A3B.00531292.00@d06mta07.portsmouth.uk.ibm.com>

"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.

Received on Friday, 27 April 2001 11:08:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC