Re: Revision names
ÿ (infonuovo@email.com)
Tue, 12 Oct 1999 09:26:01 -0700
From: <infonuovo@email.com>
To: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Date: Tue, 12 Oct 1999 09:26:01 -0700
Message-ID: <002801bf14f2$0587f2e0$0100007f@conclave>
In-Reply-To: <85256808.0051DD87.00@d54mta03.raleigh.ibm.com>
Subject: RE: Revision names
I don't think the problem is one of revision-id and revision-label being
from the same namespace so much as the requirement that they partition the
namespace. I don't see any way for a client to know how that works without
an out-of-band agreement among all sources of revision-id and revision-label
assignments for a given DeltaV server.
Is it not the case that the revision-id is exclusively assignable by the
server, so that it is always possible to avoid duplication of a revision-id
assignment? (Requiring that a revision-id never duplicate an assigned
revision-label strikes me as raising the cost way beyond marginal utility,
but it is certainly possible to honor that if DeltaV were to require it.)
I think I am missing something about the requirements, or user models, that
are behind the different stances on this topic.
-- Dennis
Dennis E. Hamilton
- - - - - - - - - - - - -
mailto:infonuovo@email.com
tel: +1-206-779-9430 (gsm)
http://www.infonuovo.com
-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
jamsden@us.ibm.com
Sent: Tuesday, 12 October 1999 07:53
To: ietf-dav-versioning@w3.org
Subject: Re: Revision names
We can think of the server as another collaborator in distributed authoring
systems, one that provides a set of services. In particular, there can be
little
distinction between a revision name (something that distinguishes one
revision
from another in this context) specified by some other client and one
specified
by the server. In both cases there is the possibility for collisions, and in
both cases, there is the desire to use the revision name to select a
revision.
As Tim points out below, there is also a desire for the syntax of label
names to
be consistent with URLs, and to be able to marshall revision names in
request
and response entity bodies (in XML) as well as in headers. The only
difference I
can see is that the server's revision name, the revision id, can't be moved
or
reused - its an immutable or fixed label that ensures revisions can always
be
distinguished. Any attempt to move or reuse the label id results in an
error.
This makes potential client/server collisions even safer than client/client
collisions as there is no possibility of some other client getting an
unexpected
revision because some other client or the server moved the label id.
The only reason to separate id and label name spaces seemed to be to avoid
client/server label name collisions. But it is clear that client/client name
collisions are much more likely to happen, and have greater consequences (as
measured by the principle of least astonishment). I continue to find it hard
to
justify the complexity separate label namespaces adds to the protocol vs.
the
problems it solves. Does anyone else see other issues that separate
namespaces
would avoid?
Tim_Ellison@oti.com (Tim Ellison OTT) on 10/12/99 10:26:17 AM
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
cc:
Subject: Revision names
As mentioned by both Jeff (by phone) and Geoff (in an earlier positing),
revision id's must be legal URI path segments if we envisage the ability to
refer to a revision by a URL (i.e. DAV:history's revisions collection "/"
DAV:revision-id).
Maybe we will also want to refer to a particular labelled resource by a URL
in a similar fashion.
If we choose to differentiate labels and revision id's by extra syntax
surrounding the value this would lead to bizzare looking URLs.
Having listened to the discussions, I think that the argument for avoiding
collisions between labels & revision ids has been largely debunked; and the
protocol would undoubtably be simpler if there was not requirement to
separate namespaces. However, labels and revision ids have different
characteristics from the client's perspective and it would be immensely
reassuring to know which you are dealing with at all times. I just don't
see yet how this would fit into the protocol.
Tim