Re: Configurations: A Compromise Propos
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sat, 8 May 1999 07:08:13 -0400
Date: Sat, 8 May 1999 07:08:13 -0400
Message-Id: <9905081108.AA09964@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Jeff_McAffer@oti.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <1999May07.182700.1250.1172832@otismtp.ott.oti.com>
Subject: Re: Configurations: A Compromise Propos
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
I agree that configurations are fundamentally mappings from
versioned-resource-id to revision-id.
Yes, that is always a good thing to keep in mind. In particular, sometimes
folks think that they are the equivalent of a "tar file" or a "zip file".
They are definitely not that. They are mappings from versioned-resource-id's
to revision-id's. Now you can *create* a tar file or a zip file from a
configuration, but you now have a tar file or a zip file, *not* a
configuration.
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.
If you want to persistently remember a name for a resource, you save
a collection that gives it a name.
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.
The analogy with a zip file is likely to be misleading, since a zip
file creates a copy of a set of data, not a mapping, but lets see
what we can do with it.
When you "zip" a file, you are not only putting your tree onto the
tape, but you are *also* modifying a single collection (named "/")
that already exists on that tape. If you chose to modify that collection
by adding a member by the name "foo", that's fine, and now the zip
file knows that you want that subtree to be named "foo".
If you recognize that "/" is itself a resource that must be modified
if you want to have a member called "/foo", things become clearer.
In your examples, (1) is modifying "/" to contain trees whose
names are the same as their binding in "foo", and (2) is modifying
"/" to contain a single tree, which you have named "foo".
In the first case, you are editing "/" and adding baselines of each
internal member of "foo", and in the second case, you are editing "/"
and adding a single baseline. The name you wanted to remember is
captured by your edit of "/".
If I add several collections to a configuration, how do I tell them
apart?
You need a single additional collection resource that gives each of them
a name. And then all you need is a baseline of this additional collection,
and you have everything you need for that configuration. So if you
care about the names of roots, you'd always use a "baseline" and not
a "configuration" (which is why I care much more about baselines than
I do about configurations).
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.
You would only do this if you didn't care what the names of these 3 root
collections were. If you cared, you'd have a parent that contained
those 3 root collections and gave them a name, and use a baseline instead
of a configuration.
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, ...
You'd get this from this parent collection that you added in once
you decided you cared about the names.
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.
You could do this, but then when you decided not to actually use
that name (perhaps you couldn't because there already was a resource
that had that name), you are stuck with this property saying that this
resource should be called "foo", when it *actually* is called "foo.old"
and some *other* resource is called "foo".
You could just as easily have the convention that there is an extra
collection that contains all the top level names. A tool strips off
this top-level collection, but uses it as a hint of what the names
of the children should be. If the tool choses not to use the old names,
there is no confusion ... they are just part of the stripped off parent,
not part of the child where they might collide with reality.
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
Having the computer "do some work" (they're really good at that :-)
is much better than leaving incorrect or misleading "naming" properties
around on resources.
- 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.
The convention that you have a top level collection that gives a name
to all its internal members is no harder for programs to deal with
than a convention that asks them to look for some "suggested-name"
property when they use a configuration for the first time. It certainly
isn't ambiguous.
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.
If you accept that only collections can give resources names, then
when you "mount" a baseline and you want the name of the baseline to
be the one it "originally had" (or at least, you'd like it to be if it
doesn't clash with a name you already have), then the only way to find
that name is to get it from the root collection. So there is no
ambiguity ... you always strip off the root.
If on the other hand, you have the convention that you don't care what
the name originally was, then you can just mount the root of the
baseline under whatever name you want. In either case, it is just
something that the user of the baseline is inherently free to decide,
not some ambiguity in the representation.
Cheers,
Geoff