Re: Revision identifier and revisions label namespaces
Chris Kaler (ckaler@Exchange.Microsoft.com)
Wed, 6 Oct 1999 14:14:15 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD934@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Wed, 6 Oct 1999 14:14:15 -0700
Subject: RE: Revision identifier and revisions label namespaces
Since I feel somewhat responsible for the whole "same namespace" issue,
let me explain how we got there.
At the time, we weere talking about a way for a client to indicate
which revision they wanted. This could either be a revision-id or
it could be a revision-name.
At the time, there was a desire to have a single header. This is
why we created the term "revision-name". It was a way to refer to
either an id or a label. This, naturally, led to a single header
which could accept a label or an id.
Given this design, I wanted a simple way to look at the header and
determine if it was a label or an id. Since there was a single
header, that meant that there was, conceptually, a single namespace
for all this data.
With 2.2 we still have a single header, Target-Selector. As described
in 4.4.1, this accepts either a label or an id. I'm happy to make
the namespaces different, but I do believe that servers need to know
the difference. I'd be happy with something like the following:
target-selector := "Target-Selector" ":" target-sel-item
target-sel-item := target-sel-id | target-sel-label
target-sel-id := "ID" "(" string ")"
target-sel-label:= "LABEL" "(" string ")"
Thoughts?
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Wednesday, October 06, 1999 1:35 PM
To: ietf-dav-versioning@w3.org
Subject: Re: Revision identifier and revisions label namespaces
From: jamsden@us.ibm.com
<deh>
It makes no sense to have an user-meaningful label and a system-assigned
unique identifier have anything to do with each other. One is for the
internal integrity of the implementation and preservation of the model.
The
other is for what people or clients agree to use.
</deh>
<jra>
This is not really the case. When a user checks out a revision a
working resource is created. The workspace rules automatically select
working resources over any other revision. If a user just checked in
the resource and never labeled it, then a revision would exist that a
user had no way to reference. The revision id isn't for internal
server implementations (although servers are free to use it for
whatever purposes they desire), its to ensure that all revisions of a
versioned resource can be distinguished. Think of it as the initial
label for a revision, one that can't be removed or moved, so you
always know what you're going to get.
<jra/>
I agree with Jim's characterization of ids and labels, but I'm not
sure that it conflicts with what Dennis wrote. The fact that both
id's and labels are used by clients to identify revisions is not
incompatible with the desire to keep the namespaces separate.
From: jamsden@us.ibm.com
<gmc/> For any given server, I agree that there could be a simple
rule that partitions the namespace between identifiers and labels.
If you have a client trying to run against several servers,
it could be frustrating to keep colliding with different server
conventions.
<jra>
I don't think the server-generated ids are likely to cause
many collisions, so I don't think we really have that big a problem
here. </jra>
<gmc/> As you indicated above, server-generated ids are the default way
to access arbitrary revisions of a versioned resource. Since clients
will be using these id's to do selection, I believe servers will be
motivated to make these id's fairly sensible (e.g. small integers).
But the more sensible they are, the more likely they are to collide
with a "sensible" label. Since we don't want to constrain the id
namespace, I believe that leaves a client with a significant risk
of having a label collide with some server's id convention.
and collisions are easy to handle. The
server will simply refuse to add the label to the revision and the
user will pick something else.
<gmc/> You never collide with a label ... you just cause that label
to be moved to the revision you specified. But you can collide with
an identifier, since that is server assigned and cannot be assigned
(or reassigned) by a client.
<jra>
We may want to rethink this. Having a label quietly move from one
revision to another may not be what we want. Perhaps we should require
a drop/add paradigm rather than simply label. If not, then I still
don't think this is much of a problem. There may be other reasons a
server can't support the label, so the error could still occur.
</jra>
<gmc/> I believe the case where you want to move a label (as opposed to
create a new one) will be the most common (or at least, very common),
e.g. label something "stable" or "recommended". In this case, you
cannot detect a "good collision" from a "bad" one. As for there being
other reasons a server cannot support the label, I believe that should
be a rare occurrence for well designed servers.
This is the same thing that would
happen if the revision already had that label for any other
reason.
<gmc/> That is a good point, but it is still a very different case
(one is a collision that fails the label request ... the other moves a
label that someone was using for something else). Also note that the
label problem occurs only if someone has chosen that exact label for a
revision of that versioned resource. The identifier collision occurs
whenever your label has the syntactic shape of an "identifier" for
that server, even if there is no such identifier on that versioned
resource, or even on any versioned resource.
<jra>
Labeling a revision with the same label twice should return an error.
</jra>
<gmc/> A common scenario is "label everything in my workspace with a
particular label". You don't care if it already has that label, so to
force the client to do two round trips (first check to see if it
already has that label, then do the label if it doesn't) would seem
unreasonable.
Nothing has to be remembered when the label is used in a
target selector. All in all, I think this is easier for clients, not
additional burden. </jra>
<gmc/> I believe that benefits of avoiding label/identifier collisions,
combined with the likelihood that a client would need to distinguish
when it is using a label vs. and identifier anyway, outweighs any
benefits
that might result from unifying the namespaces.
<jra> I believe the opposite. The likelihood of collisions occuring
when adding a user label is much smaller than the need to remember and
distinguish label namespaces when accessing the corresponding
revisions. One accesses revisions a lot more often than one labels
them, and the consequences of the collision are minimal. The user
just has to pick another label. </jra>
<gmc/> The client program is happy to keep track of
To:
Subject:
--text follows this line--