Re: Revision names
Chris Kaler (ckaler@Exchange.Microsoft.com)
Tue, 12 Oct 1999 10:55:16 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD984@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Jeff_McAffer@oti.com'" <Jeff_McAffer@oti.com>,
Date: Tue, 12 Oct 1999 10:55:16 -0700
Subject: RE: Revision names
<jm/>
No one is talking about the ids as the server sees/uses them but rather
how their server exposes the ids to the client. Saying that it has to be
a URI means sticking 'dav:' or some such on the front of the string
before sending it out. Saying that it has to be a valid URL segment
means ensuring that the chars are URL encoded before sending. Have I
missed a case here?
<ck>
I certainly agree that internal ids are different from exposed ids,
however, requiring a server to transform these into a specific pattern
seems wrong to me. I'm not suggesting they must be URIs, but a server
should have the option. Actually, I believe they should be URIs and
have suggested that in the past. If we consider the "distributed"
aspect, if we have history across multiple servers, and objects that
move between servers, using URIs is a good thing. But my real
concern here is dictating how a server must present information.
<jm/>
I believe it would be a tremendously good idea to allow construction of
revision-specific URLs from constituent parts. Again, no one is saying
that your server has to actually store things in any particular way.
Think of the fully-qualified URL as you would think of a servlet or .asp
URL. There server does not blindly go off and return whatever is at the
end of that path. Heck, some servers don't require any resources at all!
The server interprets the path. All we should be concerned about here
is that the URL contain sufficient data to allow the server to figure out
what actual set of bytes are needed. How it does that and how it
accesses the bytes are entirely up to it.
<ck>
I can see the value of this, and that was the motivation for property
collections. But I think this should be optional. Combining segments
of URLs is really like URL munging and I'm worried that we will define
a standard that has problems. Servers should be allowed to treat these
as opaque strings which they interpret.
<jm/>
Can you clarify what it you mean by "property resource collections" and
what it would mean for a server to not support them?
<ck>
These are Geoff's idea where you have, for example, a history URL that
refers to a collection in which there are entries (BINDs) for each
revision and label.