Re: Configurations: A Compromise Propos
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Mon, 10 May 1999 11:49:50 -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: <1999May10.114846.1250.1174242@otismtp.ott.oti.com>
Date: Mon, 10 May 1999 11:49:50 -0400
Subject: RE: Configurations: A Compromise Propos
I don't want Geoff and my disagreement on this issue to cast a pall over
the proposal as a whole. This is a minor point in the grand scheme of
things and short of this, I restate that I agree with the "compromise"
proposal.
Having said that, on with the disagreement...
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>
> From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
>
> 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.
Actually, I disagree but realize the analogy can only be pushed so far.
I disagree because whether or not the data bytes are copied is
irrelevant. Imagine that Zip/tar just captured the FAT or inode to block
mappings rather than copying ...
> 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 "/".
yes. I fully understand how names of resources are captured. The issue
is not *how* it is done but *who* does it! Notice in your description
you talked about "/" already existing etc. "/" was provided by the
system. Users are not forced to create "/". Its just there. Under the
covers there are inodes, FATs, blocks ... but users don't care, they just
copy "foo" and then see "foo" in the list of contents of "/". I am
proposing a somewhat analogous setup for configs.
I argued that if you leave it up to the programmer (after all, it is she
who has to create the "root" colleciton and then add the real roots) and
to convention, that it was
1) too much work (in terms of round trips and coding)
2) open to inconsistency because it is just a convention
#2 is the one that bothers me the most. Say I use the convention that I
always use a name-capturing-root-collection. All my code is written to
take a config and strip off the root to get the list of the real roots
(vice versa for creating configs). say you're system doesn't do this
because you don't care about root names. Lets assume that my system is
resilient to this and (conceptually) can choose names if none exist. How
does my system tell what the "real" roots of the config are? My configs
have name-capturing-root-collections but yours don't. The issue is not
deriving the names but the ambiguity in determining the real roots. The
name-capturing-root-collection is not part of my domain. It is a
mechanism I was forced to inject to retain the names of my domian roots.
As for #1, it is unclear to me what roundtrips would be required to do
all this. Here is what I think might be going on. Perhaps one of the
protocol gods can write the correct version?
1) MKCOL to create the name-capturing-root-collection.
2) MKREF/BIND (or whatever the current incantation is) to add
each "real root" to the naming collection. (can be done
with one call for all?)
3) Create configuration
4) add COL #1 to the config
5) snapshot the config
Versus
1) Create configuration
2) add the real roots to the config (inherently remembering the root
names)
3) snapshot the config
I could imagine (and wish for) a protocol which combined the create
config, add roots and snapshot into one round trip. In that case, the
ratio is even worse! (3:1 rather than 5:3).
> 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.
Exactly! except I am arguing that this be provided by the system in
(perhaps) the form of a property on the configuration. The property has
this name-capturing-root-collection and is created/maintained for you
when you put roots into the configuration.
> 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.
If you tell me the protocol will be such that the same number of
round-trips will be required then I remove this objection. Otherwise
round-trip count rules.
> 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.
If there is no "suggested-name" property (or it is empty) then I know
there are no suggested names (unambiguous). With the
name-capturing-root-collection *convention* I have no way of knowing if
the creator of the config was adhering to the convention or not
(ambiguous). Further, with the property approach, I *know* that the
roots in the config are the "real" roots as they exist in my domain
(again, unambiguous).
Jeff
BTW, are we imagining that configurations have names?