Re: Version identifier in URL

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Previous message: Fabio Vitali: "Re: First cut at Functional Requirements document"

>There are two scenarios possible in a "hierarchical version
>space":
>
>	http://host/prefix/VERSION/suffix
>
>and
>
>	http://host/prefix/suffix/VERSION
>
>The former has the advantage that, in the general case, we can
>specify a version for a subtree, which lets us "surf into the
>past" for free.  The latter has the advantage that, in a sense,
>different versions of a particular node in the heirarchy are
>subordinate to it.
>
>Unfortunately, neither option addresses the practical concern
>that the server has to have some way of determining
><strong>when</> a URL contains a version. I mean, the path
>
>	http://host/foo/1.5/bar.html
>
>could easily reference a page discussing the history of the "bar"
>facility in Lisp 1.5.

You have to be extremely forgiving with me, but, maybe because english is
not my first language, maybe - probably - because I'm dense to this
arguments and simply stupid, in those cases when one is presenting a
paradox he should always give both sides, so as to make it exactly clear
that it is indeed a paradox.

Now your example here definitely looks like a paradox for the way it is
phrased and the implicit sentences: "could easily reference XXX [and we
obviously don't want that]" or "could easily reference XXX [as well as YYY,
and this is ambiguous]". And, in your example, I'm missing something. I
really don't see the problem. No paradox for me.

In my view, the server never can have any problem in determining whether a
URL contains a version or not, except for that damn example of the Thoth
operating system that has me here in Sardinia tending stupid goats. The URL
is opaque to the client, not to the server. Since it is the server that
provide the rules to build a URL (e.g. the directory path, the home
directory, etc.), it also has to provide a rule to decode it. And to use

>	http://host/prefix/VERSION/suffix

or

>	http://host/prefix/suffix/VERSION

is a policy decision of the server, that we are not in the position to rule
about. Indeed, I would appreciate a system that provides both, so that I
can use either one in my client: the first syntax to use relative URLs to
"surf into the past" (i.e. to get the correct versions of the documents and
images associated to "suffix"), the second syntax to use relative URLs to
"surf *across* the past" (i.e. access different versions of document
"suffix" - for comparison, merge, or whatever), both extremely valid and
justifiable requirements.

The point for the server therefore is not how can the *server* know about
versions, but what kind of "surfing" is the server going to provide ("into"
or "across") by using relative URLs.

The problem on the other hand is how an aware *CLIENT* can know about
version information. This is a tough one. So we have two cases:

a) The client is version-unaware, and therefore any kind of version-related
operations must be dealt with by the user manually or by existing and
acceptable
techniques (e.g. relative URLs). In this case it is necessary that the user
understands, possibly at a glance, about the policies used by the VCS at
the server, so that she can directly create URLs for related resources
(across or into the past) and ask for them in the "Goto:" field.

b) The client is version-aware, and therefore can deal with version-related
operations autonomously. In this cases: we have two additional issues: if
there is a single acceptable policy, then a version-aware client could use
different VCS systems (for example, in different HTTP servers) without
modification to the code. Otherwise, if no single policy has been found, it
is necessary that either the client is VCS-specific, or has code for
managing all the different VCSs at the servers.

Since having a single acceptable policy implies not just agreeing on how to
store version information in the URL, but also on how to deduce the URL of
the resource returned by the existing VCS operations (e.g. previous
version, next version, latest version in which Bill provided a
modification, etc.), I would think that this is, currently, an overly
optimistic goal.

To summarize, the hierarchical specification is not a problem neither for
the server, nor for unaware clients, in my view, but only for version-aware
clients that have to deal with several different policies. This leads, most
probably, to specialized clients aware of only one specific policy, i.e.
working in an aware manner with only one VCS. I personally do not see a way
out of this.

Fabio

• Previous message: Fabio Vitali: "Re: First cut at Functional Requirements document"