Re: Discussion Topic: Simple Version Selection and Checkout
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 29 Jan 1999 14:20:39 -0500
Date: Fri, 29 Jan 1999 14:20:39 -0500
Message-Id: <9901291920.AA22534@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <85256708.00560444.00@d54mta03.raleigh.ibm.com>
Subject: Re: Discussion Topic: Simple Version Selection and Checkout
Note: I continue to favor Jim's proposal to specify DM versioning via
a simplified workspace mechanism, but I would modify some of the details
he introduces below.
From: jamsden@us.ibm.com
From: gclemm@rational.com
(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. ...
(3) Although you can access an arbitrary revision (since every revision
has a URL), only a revision exposed in a workspace can be modified. ...
... once multiple versions are introduced, there must be some way for
users to refer to a particular revision of a resource. ...
1. Munge the URL and include the label for the revision. ...
Also, whether it is URL munging or not, it makes all inter-resource references
totally brittle (i.e. all documents containing references would have to
be modified whenever you created a new revision of a document they refer
to) so we can discard this approach out-of-hand.
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.
Also same problem as choice 1.
(Jim: You seem to have skipped choice 3. :-)
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.
Also, since clients would need to save these revision mappings for
use in a future session, and share these version maps with other clients,
not defining a standard way to store and share this revision selection
information would pretty much eliminate any significant interoperability.
5. Use the primary rule of patterns: factor out the thing that changes into
a separate object and delegate. This is the workspace approach.
Yes.
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.
Here I must partially disagree.
I agree that the original URL (of the resource before it was put under
version control) should be usable to select any of the revisions of
that resource (based on the workspace revision-selection-rule).
I also agree that this is the URL that you must use to modify the
body of a revision.
But I strongly disagree that the versioned-resource and all the
revisions should (or even could!) have the same URL (as each other, or
as the original URL). The versioned resource must have its own
(server allocated) URL, because when you make it visible in several
places in the URL space (which is a common requirement of document
management systems), you don't want the versioned resource to disappear
everywhere just because you have applied a "delete" to the original
URL. You could play some games about the "real" versioned-resource
moving around to one of the other URL's, and then automatically
updating all the other URL's that refer to it, but that's just a good
way to tie yourself into knots (and step smack in the middle of the
"strong references" minefield).
In addition, given the desire for maintaining "history", you want a
a URL that can get you to the versioned resource, even after all current
references to it have been deleted, and having the server generate
a URL for the versioned-resource that is separate from the original
gives you that ability.
Now as for the revisions having their own URL's, clearly they can't just
have the URL of the original resource (for similar reasons for why the
versioned-resource can't have the URL of the original resource). Since
they each will be given a unique id (wrt to versioned resource), clearly
it would be easy for the server to give them each their own URL, and then
we wouldn't have to pass in a "revision-id" header every time we wanted
to look at some revision that is not currently visible in our workspace
(for example, when merging).
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.
I agree with everything here. One comment: although there will be a
default revision-selection-rule for the default workspace, a client would
be able to modify the revision-selection-rule of the default workspace.
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.
If you want to expose different revisions of the same versioned resource
at different URL's in the same workspace, you would need to say which URL
should pick the one revision, and which should pick the other. But if
you don't need/want to do this, I agree that there is no need for URL
specific clauses in the revision-selection-rule. But for folks that do
want to do this, it's important that they know how it would interract
with workspace-based revision selection.
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.
Actually, the issue I was raising wasn't that "there would be a
revision you couldn't put in a workspace" (with an appropriate
revision-selection-rule you can make any revision appear a workspace),
but rather that you can only apply CHECKOUT (and then PUT) to a
revision using it's original URL (what the protocol calls a
"vportal"), and *not* using the URL of the revision.
In your description, this is trivially true, because you weren't going
to allocate a separate URL for the versioned-resource or any of the revisions.
And I agree that this would be an advantage of not allocating those
URL's, but unfortunately I really care about the baby swimming in that
bathwater (:-).
Cheers,
Geoff