Re: How to create configurations

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 6 Apr 1999 09:35:06 -0400 

Date: Tue, 6 Apr 1999 09:35:06 -0400
Message-Id: <9904061335.AA27755@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525674B.003FB5D3.00@d54mta03.raleigh.ibm.com>
Subject: Re: How to create configurations

I neglected to mention a key element of my "scheme" for allowing
relative URL's in the DAV:scope of a snapshot (complements
to Jim Amsden for detecting the incompletencess of the proposal).

For this to work, a versioned-collection needs to be associated with a
*single* versioned-snapshot.  So only *one* versioned-snapshot can be
associated with a given versioned-collection.  This would be modeled
by associating an optional DAV:versioned-snapshot property with a
versioned-collection.

As the server is traversing down the sequence of nested
versioned-collections (using the workspace revision-selection-rule
to select a revision of each versioned-collection in the sequence),
if it encounters a versioned-collection that that has a
DAV:versioned-snapshot property, then it applies the workspace
revision-selection-rule to this versioned-snapshot to determine
which snapshot should be used.

Jeff McAffer: note that this does give you a restricted form
of the "LATEST(snapshot)" functionality you were requesting.
Does this restricted form suffice for your needs?

Also note that this 1-1 linking of a versioned-collection to a
versioned-snapshot effectively provides you with an optional "deep
membership" versioning of a versioned-collection, to complement the
"internal member" versioning provided by the versioned-collection
revisions.

Final note: Unless people are *very* interested in this relative
URL scoping proposal, I would suggest that we *not* put it in the
base spec, but leave it for a supplemental "add-on" spec.  It's
not something that is currently supported by any system that I
am familiar with.

Cheers,
Geoff

   "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 04/06/99 12:26:10 AM
   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