Re: Fw: Discussion Topic: Simple Version Selection and Checkout
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 31 Jan 1999 00:28:44 -0500
Date: Sun, 31 Jan 1999 00:28:44 -0500
Message-Id: <9901310528.AA23157@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <005201be4cbc$f3cb4460$944406d1@honey-bee> (sv@crystaliz.com)
Subject: Re: Fw: Discussion Topic: Simple Version Selection and Checkout
I think that Sankar, Jim, and I all agree on the key point, namely that
users (and tools) want to deal with normal understandable URL's, not URL's
that have been munged and mangled with labels or server-defined
transformations.
So both Jim and I have proposed that all mapping be done by headers and
resource properties, not by URL-munging. I had proposed that Document
Management have one property and header (namely, a Mutable-Revision-Name)
and Configuration Management have another (a Workspace). Jim proposed
that we simplify the protocol and just use a Workspace in both cases.
(And I like Jim's proposal better than mine.)
So these "labels" that Jim and I talk about are just something that
the client uses to tell the server what the user wants to see in a
given workspace, *not* something the user needs to explicitly manage.
To confirm we're all on the same page (or at least, in the same book :-),
I'll go over Sankar's note in detail.
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
>What other "manual" selection are you suggesting that would not involve
>something like labels. A URI is a name of a resource. A label is just a
>name of a particular revision of that resource.
It appears that you and Geoff are actually in disagreement about the above
statement (correct me if I am wrong).
In preceding protocol proposals, a label has always been a name, while
in my recent proposal, I have suggested we make it a URL. This change
has the very limited purpose of making label updating more reliable.
In my proposal, you cannot use a label URL to see the body of a resource,
(you would have to use a vportal in a workspace to do that), so Jim and
I agree on the functionality that a label should (and should not) provide.
Anyhow, I have a specific use case
point and a broader architecture point.
1) Architecture point
Let me start with the architecture point. Configurations, IMHO, define an
alternate namespace. The objects associated with the names could be 'bound'
using a one to one mapping between names and objects and using a selection
rule based on attributes of the object.
In my proposal, I was using the term "configuration" to refer to an immutable
resource that does the first kind of mapping (i.e. 1-1 mapping between names
and immutable-revisions), and the term "workspace" to refer to a resource
that defines a mutable mapping via a revision selection rule.
The labeling scheme I thought was the second kind
Yes.
and the explicit naming as seen in traditional version
control system I thought was the first kind.
You find both concepts in most traditional version control systems.
In particular, you find some persistent mapping of names to immutable
revisions (e.g. a file containing an "S-List" in traditional SCCS systems),
and a workspace or "sandbox" where a mutable mapping is located.
I would like to see the
architecture of the configuration namespace mechanism to be similar to
other
namespace mechanisms inside DAV and outside so that one could leverage
implementations and implementation experience. In particular, if you look
at
the ADSI spec. from Microsoft or JNDI spec. from Javasoft, they provide two
ways of resolving names to objects - explicit naming and selection by
attribute. The collection mechanism in DAV (should) also provides similar
mechanisms. If our scheme is similar in nature, we could use leverage
implementations and expertise across different types of namespaces, but
using the same type of framework.
We need to be a little careful about where we look for analogues. The
problems faced by parallel development, with branching and merging,
introduces complexities that are often ignored by general namespace mapping
mechanisms. In particular, the notion of a set of changes that need to
be applied together is a key notion underlying effective version management,
which makes it more akin to database transactions, than to namespace
management. But we *also* want to manage the namespace, which is what
makes the problem so "interesting" (:-).
2) Use case point
..., in authoring documents, it makes it much easier if
explicit names are used to do link checking and deployment.
Yes, I (and I'm sure, Jim) completely agree, as long as the explicit names
are not to specific revisions, but rather to "what your workspace is currently
selecting at this URL".
If instead you try to store explicit revision URL's in your documents,
(not that you were suggesting this, but just to emphasize the point)
any update to a document requires finding and updating all other
documents that pointed explicitly to the previous revision of that
document. Since all those other documents are under version control,
they need to be checked out and a new revision created for them as well,
which means all references to *them* must then be checked out and
revised, which means ... any change pretty soon requires a modification
most documents in your web site (not to mention all documents outside
your web site that stored explicit revision references).
It's this scenario that makes us pretty devoted to the "everything goes
through a workspace" approach.
I have sense
that you folks think of a configuration or workspace in the software
development sense of the word. One could think of an HTML document itself
as
a configuration. In this case, an author will not typically be referring to
(i.e., linking to) multiple versions of the same document. The author would
like to refer to a linked document with an explicit URL reference. In this
kind of authoring mode, selecting a URL of a linked document using labels
is
foreign to the author and more importantly to the authoring tool.
We need to carefully separate what the user sees and does (which is defined
by his GUI) from what protocol the client uses to communicate this to the
server. The user can say "I want a new revision of this URL". The client
then can ask the server to create a new revision (CHECKOUT-NEW), and then
ask the server to place a label on this revision so that it will appear in
the user's current workspace. The user gets to see the desired new revision,
and never has to know anything about labels.
I am making several points here:
a) That document authors would prefer to use direct and explicit references
( use case style point), and
Agreed, with the caveat above that these are direct and explicit
references to workspace URL's (what the protocol calls "vportals"),
not to specific revisions.
b) Tools such as link checkers and deployers can deal with explicit
references much more easily than resolved names based on attributes (i.e.,
labels)
Yes. (The server does all the workspace name-mapping for those tools).
c) If one were to consider an HTML (or XML + XML Link) document itself as a
configuration, then label based selection involves cooperation by authoring
clients. I believe that this would be harder to achieve as compared to
browsers/DAV clients providing the same functionality.
I didn't follow the point being made in c).
Does this all make sense to you folks?
Bottom line: I am arguing for providing explicit names and attribute based
selection. I am also arguing that the specification of this part of the
protocol should be similar to DAV collections and other namespace/directory
mechanisms out there.
Explicit names: Yes, but not to specific revisions.
Attribute based selection: Yes, in a workspace revision-selection-rule.
Similar to DAV collections: Yes, in that it is based on DAV collections
(i.e. a DAV collection provides a single segment in the URL path).
Simiilar to other namespace/directory mechanisms out there: Well, depends
on which other mechanisms, and what you mean by "similar".
Cheers,
Geoff