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

Re: Re (4): collection version resources

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Tue, 16 Jan 2001 11:32:38 -0500 (EST)
Message-Id: <200101161632.LAA17351@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

OK, unless someone else wants to keep the discussion alive, I'll follow
Tim and Greg's lead and leave the workspace option independent of merging,
baselining, and activities.

I think the "client-workspace" suggestion only makes sense in the context
of a workspace option that includes these other options, so I'll retract
that suggestion as well.


   Date: Tue, 16 Jan 2001 07:57:55 -0800
   From: Greg Stein <gstein@lyra.org>

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


   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 11:33:30 UTC

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