- From: Jim Amsden/Raleigh/IBM <jamsden@us.ibm.com>
- Date: Thu, 12 Oct 2000 13:56:40 -0400
- To: ietf-dav-versioning@w3.org
- Message-ID: <OFCC100093.A0C49C7A-ON85256976.00617F47@raleigh.ibm.com>
Geoff, Great stuff! A couple of comments. Another reason for using workspaces is that sometimes the tools required to edit, compile, or otherwise operate on a resource have to exist on a particular platform. That is, they cannot just be files in the user's local (Windows or UNIX) file system. Workspaces provide a uniform way of addressing resources regardless of where they are, or what versions are selected. But this raises an issue for testing on the server. Say you are testing a Web application, not an unusual situation for a WebDAV client to be in. Now the web server needs to see the same workspace as the client in order to test the resources just edited. This is the scenario you describe below. But often web server plugins (Servlets, JSP's, ASP's, CGI programs, ISAPPI programs, Apache modules, etc.) don't go through a nested HTTP request, they access files directly using the file system. This won't work unless the files are materialized on the server since the file system is not likely WebDAV versioning enabled. Workspaces can help this problem if their contents are mirrored in the server's file system. But then this limits the number of concurrent tests on different workspaces that can be done. Any thoughts on this area? From: Greg Stein <gstein@lyra.org> Well... as a counterpoint argument: I've never viewed workspaces as a central concept. I've always found them rather bothersome. That darned Workspace header just felt a bit wrong to me. Thankfully, I could implement a lot of DeltaV and just completely disregard the workspace concept. You are maintaining a copy of the versioned resource tree (sometimes called a "sandbox") on your client I assume, for local builds, disconnected use, etc. ? Now what if you wanted to represent that sandbox on the server? That's what a workspace is. Here's some additional motivation I'll be adding to the "Workspace" section of the protocol: ----------------------------- It is often desirable to allow several clients on behalf of a single user to access a related set of checked-out resources. In particular, this allows a user to access these resources from several physical locations, such as from another office, from home, from a remote site, or while traveling, without being forced to prematurely checkin those checked-out resources. Sometimes it is even desirable to provide shared access to checked-out resources for several closely cooperating users (using WebDAV locking to avoid overwrite problems). If only one set of checked-out resources is required, then this can be achieved with core versioning by simply checking out the appropriate version selectors. This approach is often unacceptable because it exposes the intermediate states of the checked-out resources to every client, and does not allow for a second set of checked-out resources to be defined for a group that wishes to be isolated from the intermediate states of another group. Unfortunately, working resources do not address this problem, because although they allow multiple concurrent checkouts from a single version history, there is no mechanism for grouping related working resources into an identifiable set. A related problem is that it is often desirable to isolate clients from a logical change that involves renaming shared resources, until that logical change is complete and tested. When all clients use a common set of shared version selectors, every client sees the result of a MOVE as soon as it occurs. An additional problem is that it is often necessary to perform testing on the server rather than on the client. Since a test routine on the server has no way of knowing what working resources or what versions are to be tested, only the versions selected as the current target of the version selectors can be tested. This not only does not allow testing of a checked-out resource before checking it in, but also does not provide for any parallel testing of different configurations of versioned resources. To address these problems, advanced versioning introduces the concept of a "workspace". A workspace is a collection whose members are a set of related version selectors and unversioned resources. In order to expose multiple views of a set of related version selectors in the URL namespace, multiple workspaces may be used. In order to make a change made to a version selector in one workspace visible in another workspace, that version selector must be checked in, and then the corresponding version selector in the other workspace can be updated to display the content and dead properties of the new version. In order to ensure unambiguous merging and baselining semantics, a workspace may contain at most one version selector for a given version history (although a server may support multiple bindings in a workspace to the same version selector). ---------------------------------- Cheers, Geoff
Received on Thursday, 12 October 2000 13:56:44 UTC