- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 8 Jan 2001 07:04:36 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Mark A. Hale" <mark.hale@interwoven.com> The concept of 'client' and 'server' workspace do not make sense to me unless you are trying to use it to mean a descriptive term to describe where version control is being done. What is referred to as 'server-workspace' in the draft is a workspace that exists on the server that is client accessible. Yes, the option names (such as "client-workspace" and "server-workspace") are descriptive terms. For parallel development of several resources, you will always need something like a "workspace", i.e. a place where those resources live with appropriate relative names. In the "client-workspace" option, the workspace is on the client (and therefore have no explicit resource for them on the server), while in the "server-workspace" option, the workspace is on the server (and therefore has an explicit resource on the server, the "workspace resource"). > > And the bit about a workspace as a precondition: sections 5.5 - > > 5.7 actually work without needing "workspaces." It is a bit > > confusing because they are placed into the "workspace" section, > > when they really just mean "editing resources on the server > > [with or without a workspace]." IMO, they should move to a > > different section, or somehow be clarified that they do not > > require a "workspace" to operate. > Yeah, that was just a somewhat forced attempt to cut down on the > number of options. It seemed like the only people asking for "in > place checkout" were those who were planning on implementing > workspaces, so I bundled "in place checkout/checkin" with the > workspace option. Another way to look at it is that a server can > support the "server-workspace" option, but fail a user's attempt > to create new workspaces with MKWORKSPACE. I'd probably prefer > this over splitting this into two separate options (although I > agree that they are logically separable). I need to think about this one some more. If the version-controlled resource (VCR) is in a workspace, doesn't the workspace need to exist as a precondition regardless of whether or not a separate URL for the workspace can be discriminated? I think it is clear my "simplification" is actually confusing things, so I'll break these would into two separate options as Greg suggests, namely one option which lets you do CHECKOUT/CHECKIN/UNCHECKOUT of a version-controlled resource, and another option which lets you create separate workspaces on the server (the latter is the "server-workspace" option). Cheers, Geoff
Received on Monday, 8 January 2001 07:05:33 UTC