RE: Revision names - id patterns

Agreed, just some minor points:

The server isn't doing anything arbitrary in this case, it is just doing what
some client told it to do. So having the server move a label as the (somewhat)
indirect consequence of a client request doesn't seem that different than having
some other client do it directly. In one case the label moves because a client
created a new revision which happened to pick an already used label. In the
other case, it moves because a client labeled a revision. Doesn't seem that
different.

Brad's argument is the best one I've see so far for separate namespaces.
Unfortunately, the argument applies to every client who wants stable labels, not
just the server. This is what configurations are for as they do no depend on
fixed labels. I still think separating the namespace adds complexity to the
versioning model that is not consistent with the problems it solves. But I don't
feel that strongly about it.





Bradley Sergeant <Bradley.Sergeant@merant.com> on 10/14/99 11:29:18 AM

To:   ietf-dav-versioning@w3.org
cc:

Subject:  RE: Revision names - id patterns



In my neck of the woods it would be considered rude for the server to
automatically, unconditionally, irrevocably, and without warning move a
clients label.  I think this is quite different from having a client (who
has been given access) move a label.  Labels are used as important
indicators.  The fact that other authorized users can move them doesn't mean
that it's OK for the server to do so arbitrarily.

It's much better to keep clients from putting themselves in harms way, that
is keep them from using labels that will conflict with revision ids.  A 403
is a far better solution than automatically moving labels.  Even better
would be a separate name space.

--Sarge

-----Original Message-----
From:     jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent:     Wednesday, October 13, 1999 11:59 AM
To:  ietf-dav-versioning@w3.org
Subject:  Re: Revision names - id patterns



Good point Brad, but I don't think this is a problem. When the server
creates a
new revision, if the label name (id) it wants to put on the revision is
already
used as a user label, it will just be moved to the new revision, just like
it
would if any other client reused the label. The server guarantees it will
never
reuse this label on any other revision, and that it will never move again,
but
the first time doesn't matter. So I don't think the id space needs to be
reserved.





Bradley Sergeant <Bradley.Sergeant@merant.com> on 10/13/99 02:10:26 PM

To:   ietf-dav-versioning@w3.org
cc:

Subject:  Revision names - id patterns



Assume there is a single namespace for revision ids and revision labels.
If the server has a simple pattern for generating revision ids, then would
it be legal for it to disallow a particular grammar being used for labels?

Example:
If the server wants to use the following sequence for revision ids:
1.0
1.1
1.2
...

And a user tries to add a label "1.3", then can the server return a status
of 403 Forbidden and force the user to choose another name?  This would mean
that some labels could be added to some servers, but not to others with
different revision-id grammars.

For some servers it may not only be the conflicts of existing revision ids
and labels that matter, but also of those not yet created.

I suggest we at least grant the servers this degree of control over the
revision-id namespace.

--Sarge

-----Original Message-----
From:     jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent:     Tuesday, October 12, 1999 7:53 AM
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

Received on Thursday, 14 October 1999 13:23:46 UTC