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