Re: Re (4): collection version resources

Tim and I seem to be in complete agreement :-)

The OPTIONS response has the data they need, and my example doesn't require
baselining or merging. Consider that I have a simple client that just needs
a place on the server to make a small change. I don't need to create a
baseline containing my change, and I don't need a complex merge (my client
implements a simple policy of "edit in priate workspaces, set a label, then
update the public space").

Cheers,
-g

On Tue, Jan 16, 2001 at 02:37:39PM +0000, Tim_Ellison@uk.ibm.com wrote:
> 
> 
> Come on ... it is no more complex for a client to check for the three
> options responses if they require all that functionality.
> Nor is it complex for a client to lay down a set of consistent labels to
> get a configuration, and get a useful recovery of a configuration using a
> deep UPDATE.  I see only benefits for keeping them separate.
> 
> Tim
> 
> "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2001-01-16 02:21:14 PM
> 
> Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
> 
> To:   ietf-dav-versioning@w3.org
> cc:
> Subject:  Re: Re (4): collection version resources
> 
> 
> 
> 
> 
>    From: Tim_Ellison@uk.ibm.com
> 
>    I agree with Greg that simpler uses of workspace are feasible.
> 
> Feasible, for sure.  But since this imposes a complexity cost on
> clients, do those simpler uses warrant the cost on the client?
> 
> Note that a client can always use whatever subset of the server
> provided functionality that it wants, so if we say that a workspace
> server MUST support merging and baselining, this does not mean
> that a workspace client must use that functionality.  So the
> cost here is only on the server.
> 
> Again, I can go either way, but the fact that the primary motivation
> for the "workspace" concept is to support unambiguous merging and
> baselining does make it seem like a workspace implementation is
> unlikely to come without them.
> 
> Cheers,
> Geoff
> 
> 
> 

-- 
Greg Stein, http://www.lyra.org/

Received on Tuesday, 16 January 2001 10:57:48 UTC