Re: Versions and configurations

Christopher Seiwald (seiwald@p3.com)
Wed, 29 May 1996 22:25:52 -0700 

| Decorated URLs in the MKS style may suffice for the simple versioning
| needs. But I suspect we'll want to look at an additional HTTP method --
| call it SET_CONFIG -- to tell a server, "Now switch to serving the
| 'tables-no-frames' version of the pages."

Yikes.

Let me demur.  [ Hephaestus gloves on. ]

1)      As David Fiander points out, the example muddles content negotiation
        and versioning.  I fear that if we don't keep the two quite distinct,
        we'll have a hard time convincing people that version information
        belongs in a URL (because clearly content negotiation doesn't).

        As Larry Masinter notes, the above scheme requires state in
        conjunction with a URL, which (to me) defies the notion of a
        URL.

2)      I'm not sure that "configuration information" is distinct
        from "version information", if you don't limit "version" to be
        simply "revision" information.  That is,

                http://www.economist.com;version=May-4-1996

        can describe the whole configuration of The Economist's articles
        as of that date, while

                http://www.foo.com/something.html;version=1.2

        would pick out a particular rev of a single document.

        I don't see where lies the added value of a "configuration" over
        a versioned directory tree, but this could just be a problem
        with terminology.

David's example of http://www.economist.com leads me to another suggestion
for decorating a URL with version information: the pages on that site
are organized as http://www.economist.com/issue/_date_/_article_.  What
they've done is implemented poor man's version control, but they used
the name space (i.e. the URL) in an intuitive and natural way.

Three ways of making that a convention would be:

a.  The explict:  http://www.foo.com/a/b/version=_verions_/morestuff

    In this case, the version is identified by a specially marked path
    element.  The path element could be anywhere.

b.  The implicit: http://www.foo.com/_version_/morestuff

    Here the first element implicitly denotes the version.  This is a
    bit like the way Atria uses their view-extended path names: the
    first element is the view (which selects the the versions), and
    subsequent elements are interpreted according to that view.

c.  The hidden:   http://www.foo.com/a/b/_version_/morestuff

    Here the version, just as with The Economist, is simply an
    indistinguishable part of the path.  No one knows, except for
    the version-controlled server.

The nice part about embedding the version is that relative paths would
point to the same version across the whole document tree.  I think
that "tree * version = configuration", so it should satisfy people
who want full configuration selectability.

Christopher
----
Christopher Seiwald     P3 Software             http://www.p3.com
seiwald@p3.com          f-f-f-fast SCM          1-510-865-8720