From: firstname.lastname@example.org To: email@example.com Message-ID: <firstname.lastname@example.org> Date: Fri, 29 Jan 1999 10:35:45 -0500 Subject: Re: Discussion Topic: Simple Version Selection and Checkout ---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 01/29/99 10:35 AM --------------------------- Jim Amsden 01/29/99 10:13 AM To: "Geoffrey M. Clemm" <email@example.com> cc: Subject: Re: Discussion Topic: Simple Version Selection and Checkout (Document link not converted) Some brief clarifications. Here's Geoff's results of using CM style URL resolution for DMS systems: (1) The concept of a "workspace" is introduced at the document-management versioning level. (2) The version-selection rule is a property of the workspace, so if that rule says to do something special for URL-1 (e.g. "for URL-1, pick the revision with id R1.3.5"), and you MOVE URL-1 to URL-2, you need to update the version-selection-rule to do this special thing to URL-2 instead of URL-1. In configuration management, this is not a problem because version selection is almost always done with a floating label or "branch/LATEST", rather than a bunch of special cases for individual resources. Is it a problem for document-management? (3) Although you can access an arbitrary revision (since every revision has a URL), only a revision exposed in a workspace can be modified. This seems like a pretty reasonable constraint to me, but I wanted to make sure that wasn't just my configuration management background coming through. First, once multiple versions are introduced, there must be some way for users to refer to a particular revision of a resource. We introduced labels to provide human meaningful names for particular revisions, and configurations for refering to sets of particular revisions. But, we need some way of using these labels and configurations to access the revision they name. We also need a deterministic, controlled way of resolving references to versioned resources that don't specify a particular label. We've explored a number of approaches, none of which were without issues. 1. Munge the URL and include the label for the revision. For example, http://host:8080/myprojects/index.html;r1.0.9. This was not considered acceptable because it is not permissible to munge URLs, and labels would have to be provided for each collection in the path, not just the leaf resource. Another problem is relative URLs would also have to contain revision labels to get the right revision. Note that HTTP/1.1 does allow ; in a URL, and the text following could be used as a version label without violating any HTTP/1.1 rules. So this may not be URL munging at all. Note also that index.html;r1.0.9 referes to a specific revision of versioned resource index.html, no matter what versions of collection myprojects it may be in. So unless index.html has been removed from some version of myprojects, it's not really necessary to specify a version of the collection in order to reference a version of one of its members. 2. Require users to use an redirect URL generated by the server when the revision is created. This allows standard URLs to be used to access revisions of versioned resources, but the URLs would likely have little resemblence to the URL of the versioned resource, and would probably not be meaningful to human users. 4. Put the revision label in as a header for each resource, and provide some default if the revision is not specified. The default could be some functor like "latest". This works well for a single resource, but it doesn't scale for collections, or a large number of resources as the client has to keep too much revision information. You would need to use a revision path in the header, not just a revision in order to provide revisions for parent collections. The header would have to include labels, activities, configurations, and various functors to provide flexible URL mapping. This would be a complicated header that would have to be retained by the clients, and set for each request. The server would be unaware of any versioning context it might be able to cache between requests. 5. Use the primary rule of patterns: factor out the thing that changes into a separate object and delegate. This is the workspace approach. We leave resource URL's alone, they are the same for all revisions. The URL of a versioned resource and all its revisions is the same as the URL of the resource before it was versioned. This requires no changes to existing WebDAV clients, and supports back-level clients on versioning servers. Instead of worrying about the particular revision of each resource requested, the client creates a workspace which contains a revision selection rule that is reused for each request in the context of that workspace. The semantics of the revision selection rule are well defined, support parallel development and configurations, and are supported by the server. The client just sends a workspace URL in a header with each request, and it is used to resolve URLs to specific revisions. There would be a default workspace whose revision selection rule contained only "latest" that is used if the header is not specified. Workspaces are resources that clients can develop editors to examine and set. This works for back-level clients, DMS clients, and CM clients in a uniform way, is consistent with relative URLs, and is reasonably simple. It allows checked out revisions, revisions in the current activity, revisions with specific labels, in a specific activity, being merged in the current activity, belonging to a configuration, latest, etc. to be accessed using a single mechanism. The downside is that DMS client applications will have to set the workspace. This shouldn't be too bad though because DMS systems won't likely have multiple activities for parallel development and don't support configurations. It is likely the default workspace with checked out and latest in its revision selection rule will be adequate for most uses. For Geoff's item 2), I don't think moving URL-1 to URL-2 would require any changes to the revision selection rule in the workspace. Assume the revision selection rule contains label R1.3.5, and URL-1 has a revision with that label. When URL-1 is copied or moved to URL-2, the labels go with the revisions. So a reference to URL-2 in the workspace would resolve to the corret revision. Item 3) should also not be a problem. The workspace revision selection rule can include functor "latest" which applies to all resources. So the workspace would resolve all URLs to some revision, one that could be checked out and modified. On checkin, the new revision would be visible to anyone using this workspace. In general, putting "latest" in a revision selection rule should be avoided, and if it is included, it must be the last entry. This is because the user has not been specific about what revisions his workspace should expose, and latest is a "floating label" that moves with each new revision. This makes the workspace potentially unstable and may expose incompatible revisions. WebDAV must support latest though, and it is the only acceptable default. Well, I guess it wasn't so brief after all. This is hard stuff, but I think we're getting there. I'm keen to be sure that DMS systems are as consistent with CM systems as possible while providing the additional flexibility for mutable revisions. This will allow these systems to co-exist, and for DMS client applications to incrementally include CM capabilities over time without changing existing semantics.