Re: Configurations: A Compromise Propos
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Fri, 07 May 1999 18:30:08 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm)
Cc: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999May07.182700.1250.1172832@otismtp.ott.oti.com>
Date: Fri, 07 May 1999 18:30:08 -0400
Subject: RE: Configurations: A Compromise Propos
> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, May 07, 1999 5:39 PM
> To: Jeff McAffer (OTT)
> Cc: ietf-dav-versioning
> Subject: Re: Configurations: A Compromise Propos
>
> From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
>
[... snip ...]
> - 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.
I was just confused when I wrote that...
> - 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 agree taht configurations are fundamentally mappings from
versioned-resource-id to revision-id. My point about losing the names of
root members is not that I believe these names *must* be used but that
they can be used. Configurations are exist primarily to recover known
states. This is similar to copying or archiving (zipping) files. If I
were to add a directory "foo" to a zip file I get a choice of:
1) adding just the children of foo in a flat way
2) adding foo and having its children appear under foo in the archive
Configurations as proposed are like #2 but you loose the name "foo". You
know you have some directory in the archive, you know the names of the
members in that directory but not the name of the directory.
If I add several collections to a configuration, how do I tell them
apart? Lets say that build a configuration that has three "root"
collections. That is, I add a deep-revision for each of three
versioned-collection revisions to a configuration and then check the
configuration in. Some time later I go to use that configuration to
(re)create a web site. To do this I want to map user URL fragment (e.g.
/docs, /images, ...) to the versioned-collections in the configuration.
These vesioned-collections used to have useful names but they have been
lost. I have to somehow figure out which of the collections is the
docs, which is the images, ...
I am *not* saying that the original names *must* be used. I am arguing
for retaining the information in some way. I would be happy with a
property for example, called "roots" which maps original member name to
VRid. I don't know if this is the best approach but it gives the flavour
of what I'm after.
The solution where *you* (the client) create a collection and then add
your "roots" and then deep revision that and add that to the
configuration partially works but...
- it is too much work for (what I see as) a common case
- it is ambiguous. This "extra" collection is not part of the domain.
Unfortunately, there is no way of telling if the collection is just
there to retain name information or if it really is part of the
structure. People going to use the configuration and "mount" the VRs
don't know if they should/can ignore this collection or infact which
collections (if there are several) they can ignore and which they can't.
Jeff