Re: How to create configurations

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 6 Apr 1999 00:26:10 -0400 

Date: Tue, 6 Apr 1999 00:26:10 -0400
Message-Id: <9904060426.AA27526@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ejw@ics.uci.edu
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <000101be7fbb$12085360$d115c380@ics.uci.edu> (message from Jim
Subject: Re: How to create configurations

I believe there is a way to address JimW's concerns while still
satisfying JimA's requirements that a snapshot be "usable" in
a revision-selection-rule (which provides mappings from user-URL's
to revision-URL's).

In particular, we could introduce a DAV:versioned-collection attribute
for a snapshot.  This says that this is a snapshot of *that* versioned
collection.  In this case, all user-URL's of the DAV:scope of the
snapshot will be *relative* URL's, and only mappings of parent
collections up to the DAV:versioned-collection will be added to the
snapshot.

The main benefit of this approach is that you decrease the number of
"revision-selection-rule" conflicts in the common parents (such as
/people and /people/jim) when you mix and match different snapshots
of the children (i.e. /people/jim/project1 and /people/jim/project2).

The drawback of this approach is that the server has to become smarter,
and remember the "versioned-collection" roots of any snapshots in
its revision-selection-rule, so that it can apply that snapshot
to any child of that versioned-collection.

A compromise would be to make the DAV:versioned-collection property
of a snapshot be optional.

Cheers,
Geoff


   From: Jim Whitehead <ejw@ics.uci.edu>

   > Adding a resource to a configuration adds the URL of the resource and
   > its parent collections recursively up the collection hierarchy to the
   > root. The URL must refer to a versioned resource, and the revisions
   > selecded for the configuration must be immutable.

   Jim,

   Thanks for taking the time to write this message about configurations -- it
   really helped my understanding a lot.

   However, reading through your post, I was struck by the requirement I quoted
   above.  It seems to me there are many use cases where you don't want to add
   the URLs of parent collections all the way to the root.

   For example, if I have a Web server set up so my personal working space is:

   http://davserver.uci.edu/people/jim/

   (where other users are added under /people/)

   I wouldn't want to have /people/ added into a configuration of some project
   which starts under /jim/.  I'm hoping you really meant "to the root of the
   project" or something like that, where, if in the example above I was
   working on two projects:

   http://davserver.uci.edu/people/jim/program1/
   http://davserver.uci.edu/people/jim/program2/

   (where /program1/ and /program2/ are the root URLs of a hierarchy of Web
   resources for source code, design document, requirements, etc.)

   In this case, I would want a set of configurations for /program1/ and a set
   of configurations for /program2/ (and never the two shall meet).

   - Jim