Re: Configurations: A Compromise Proposa

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sat, 8 May 1999 05:42:52 -0400 

Date: Sat, 8 May 1999 05:42:52 -0400
Message-Id: <9905080942.AA09948@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <8525676A.0072763F.00@d54mta03.raleigh.ibm.com>
Subject: Re: Configurations: A Compromise Proposa

   From: jamsden@us.ibm.com

   I still fail to see the problem with adding collections to
   configurations meaning adding their members.

There's no problem with doing it if it is a "snapshot" (as in a
baseline), but there is a problem if you try to do it to an
incrementally modifiable set (the example I gave in my previous
message was where you added a revision to the configuration
that was a parent of a revision already in the configuration,
and then removed that parent.  Do you remove the child that
was already there, or leave it in?  Either answer will be
surprising if you had the other answer in mind when you did it.

   We had two issues:

  - how do we keep from loosing the names of the members added to the
   configuration? Both approaches have this problem, and it results from
   mapping version resource ids to revisions in the configuration for the
   members added, but user URLs for everything else. For example, a
   member of a configuration was versioned collection vr32, and the
   configuration selected r33, then that revision would contain member
   names that were from the original namespace. Why not do the same thing
   with the root members?

This is the issue Jeff is raising, but as you point out, this issue
is not related to this proposal.  (This issue is being addressed in
Jeff's thread, and I will have more comments on it there).

  - When are the revisions selected? When the member is added to the
   configuration? When the configuration is checked in? Lets do the
   simplest, safest case for now, and extend it later. That's when the
   configuration is checked in because it ensures all revisions are taken
   from the current workspace and can be known to be consistent.

It is simple and safe to do the recursive addition when the resource
cannot be modified after it is created (such as a baseline), but it
is also simple and safe to allow you to modify the resource, and *not*
do any recursive adding or subtracting (such as a configuration).

In this case, we have two (very different) simple and safe things to do,
and there is no way to decide which is "simpler or safer".  They're both
reasonable choices, but very different choices.

   I think there is too much overlap between these concepts to keep them
   both. See my comments on Geoff's differences between the approaches.

See my response to those comments (:-).

Cheers,
Geoff