Re: Name space munging ... blech!
Christopher Seiwald (seiwald@p3.com)
Tue, 11 Jun 1996 21:44:16 -0700
I don't know if I want to defend this to the death, and Jim's subject
line makes the issue seem one of taste, but I want to rally once more
behind embedding version info in paths.
I'll take Jim's points out of order:
| 3) It is impossible for a HTTP user-agent, or for a human being, to
| determine whether a directory named "1.5" is an actual physical directory,
| or a version number, without querying the HTTP server. It is extremely
I thought the URL was supposed to be opaque, and any decorating we select
is little more than a convention to make the syntax familiar.
To that end, I suggest that we decorate the version number with version=,
so that
http://host/dir/projectX/1.5/Macintosh/French/file.c
becomes:
http://host/dir/projectX/version=1.5/Macintosh/French/file.c
Aesthetics aside, this works.
| 2) Competing name space semantics: What gives us the right to partition
| the name space for HTTP servers which employ versioning? How can we
We're not seizing rights here, we're establishing a convention.
Admittedly, even /version=_version_/ takes away from the namespace
freedom of the HTTP servers, albeit less than simply /_version_/.
| 1) Legacy problem: Existing sites containing hundreds of thousands of pages
| (the current size of many large corporation intranets) will be completely
| unwilling to change their existing name space to gain the advantages of
| versioning. This is because they would be required to rewrite the
| destination URL of all anchors to versioned documents:
I would imagine that a version-aware HTTP server would take a URL with
a missing version indicator to mean the "tip" revision. I think it would
be the aware server that would implement the /version=_version_/ part of
the namespace: the underlying filestore would remain unchanged.
| 4) The main benefit of placing version identifiers into the name space,
| "surfing" into the past via relative URLs, does not work. One scenario
| outlines this:
|
| http://foo.bar.com/1.5/A.html (where 1.5 is the version id) contains a
| relative URL of GIF "../background.gif." In this case, version 1.5 of
| background.gif would also be retrieved. However, experience to date with
| versioning systems shows that all objects are not versioned at the same
| rate.
First, if the _version_ identifier is something other than a revision
number, this works a whole lot better:
http://foo.bar.com/brochure/version=_symbolic-label_/A.html
allows A.html to include a relative gif of "background.gif" and get the
desired version, whatever its revision number may be.
Second, if you allow /version=_version_/ to appear anywhere in the path,
then the aware server can have it where it most makes sense. For example,
http://foo.bar.com/brochure/A.html/version=1.15
If the server wants to let you surf, it could insert a
<base href="http://foo.bar.com/brochure/version=beta/A.html">
into the document on the way back.
The whole point is to allow version-naive clients to surf. If this is not
as important as I think it is, then maybe we don't need to go to such lengths
to solve the problem.
Christopher
----
Christopher Seiwald P3 Software http://www.p3.com
seiwald@p3.com f-f-f-fast SCM 1-510-865-8720