Re: Configurations: A Compromise Proposa

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 7 May 1999 17:38:49 -0400 

Date: Fri, 7 May 1999 17:38:49 -0400
Message-Id: <9905072138.AA08911@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Jeff_McAffer@oti.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <1999May07.155400.1250.1172615@otismtp.ott.oti.com>
Subject: Re: Configurations: A Compromise Proposa

   From: Jeff_McAffer@oti.com (Jeff McAffer OTT)

   I believe you have struck a chord here.   We have been trying to do too   
   many things with one concept (configurations).  Your proposal splits the   
   two in a useful way.  I agree with this in general and have a few   
   observations/questions.

    - Just to clarify, I can put a deep or shallow revision of a resource   
   into a configuration?  Putting a deep revision in is basically shorthand   
   for explicitly adding each of the shallow revisions spec'd in the deep   
   revision?

Yes.

    - Again, clarification.  Baselines/deep-revisions are not   
   versioned/able-resources, they are a kind of revision of a   
   versioned-resource.  How are deep-revisions identified relative to   
   shallow-revisions?  Do they just have different revision-ids?  How do I   
   (a client) tell if a revision is deep or shallow?

From a property of the revision.  I don't at the moment see a need to
require that the deep-revisions have different revision-id's from the
shallow revisions, but I'm not averse to making that requirement if
it buys us something.

    - Nesting of deep-revisions is implicit in that a versioned-colleciton   
   could (indirectly) "contain" some versioned-resource which could have a   
   deep-revision.  The job of the server when doing a deep checkin is to   
   ensure that any such nested deep-revisions are valid in the current   
   workspace.  If it is, it can be reused. 

Correct.

   If not, what?  Automatically   
   create a new deep-revision for that versioned-resource?  fail?

Automatically create a new deep-revision.  We could have a "fail" header,
but I currently see no benefit in providing that behavior.

    - I like the idea of being able to control the content of the deep   
   revision.  I also like being able to deep checkin a collection and get a   
   depth infinity revision.

By "control the content", do you mean "control the depth"?  We could
certainly provide a depth header, but I doubt that the "depth" will
have sufficient semantic content for it to be useful in many cases.

For anything but a shallow or deep (infinity) revision, I'd just recommend
using a configuration.

    - It appears that the "snapshot" operation for creating configurations   
   goes away? 

Correct.

   Just so I understand, one creates configurations then by   
   adding, for example, deep-revisions of versioned-resources (exactly one   
   per resource) to a configuration?

Correct.

    - I am not particularly happy with the use of the versioned-resource-id   
   as the member name for revisions explicitly added to a configuration.  I   
   don't know how to fix it 

Well, if you can think of an alternative, just let me know (:-).  The only
reliable information we have about the revisions is that there is only
one per versioned-resource, which means that the only id which will be
unique is the versioned-resource-id.

   but this is the problem I have talked about   
   previously where we lose the names of the roots.  This seems unnatural to   
   me.  All other resource manipulation metaphors I can think of do not do   
   this. For example, you don't lose the name of your file when you copy it   
   to a floppy.  The floppy provides a namesapce '/' for retaining the names   
   of the top level resources.  Same in zip files.

You need to think "Web" here, not floppy disk drive.  When you add to
your server configuration file an association between a particular URL
and a particular resource (perhaps, some file system file), the name of
of the "root" is not derived from the resource, but from the string you
specify in a the configuration file.

As another way of thinking about it, you should be able to "mount" any
baseline at any point in your URL tree, including "/".  If you somehow
"embedded" the name of the root of your baseline, then it could never
be mounted at "/", and it could never be mounted at any other name than
the one you embedded in your baseline.  This would be a bad thing.

Or just think of normal file system mounts.  Does a file system have
embedded in it the name by which the root of that file system *must*
be known, whenver it is ever mounted?

    - I would propose "deep-revisions" as the property name rather than   
   "baselines".

I'm flexible on what we call them, as long as the semantics are right (:-).

Cheers,
Geoff