- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 16 Jan 2001 11:32:38 -0500 (EST)
- 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. Cheers, Geoff 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"). 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 11:33:30 UTC