Re: Configurations, sets and collection
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Tue, 20 Apr 1999 12:55:15 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Apr20.125339.1250.1152117@otismtp.ott.oti.com>
Date: Tue, 20 Apr 1999 12:55:15 -0400
Subject: RE: Configurations, sets and collection
Wow, I thought I was being precise but you're right Geoff, the
terminology was really quite lax. Thanks. Basically I agree with all
the precision mods and have a little followup on "roots". (I've snipped
bits out for easier reading)
> There is a problem though. Because VR7 (A) and VR2 (X)
> are local roots,
> they have no containing collection within the
> configuration and their
> names are not preserved.
>
> I'm not sure how this can be a "problem". If you care about
> their names, you would include a versioned-collection
> revision in your configuration that gave them a name. For example,
> the revsion R5 named above.
>
> So when I mount the configuration in URL space,
> I have to somehow come up with names for these
> (potentially numerous)
> root versioned-resources. For example, how did I know to
> use 'A' when
> mounting VR7 at /foo/A in my example above? This seems
> like the 80% case
>
> to me and yet there is no place in the system to put this
> information.
>
> What is wrong with storing it in a versioned collection
> revision, just as
> you did with the other names you wanted to remember?
>
> One solution is to logically (if not physically) put these
> "roots" into a
>
> "root-collection" which maintains the namespace for VR7
> and VR2 (A and X
> respectively).
>
> How is this any different from binding a name to a versioned-resource
> in any other collection revision?
It is no different... except it encourages consistency by taking it out
of the client's hands. You suggested using VR4.R5 (which was / in the
example). That revision has members (VR1) in which I am not interested.
So I have to create some other versioned-collection to maintain names.
This resource is not necessarily part of the domain.
Consider, for example, that I want to make a configuration containing
just A (i.e., VR7.R23). To remember the resource is called A you would
have me create some versioned-collection (say VR86) (would it have a nice
URL? Where?), put A->VR7 into VR86, revision VR86 and then build the
configuration C containing VR86. A bit arduous but perhaps liveable.
When someone goes to mount the parts of C, the top-level resource in C is
some revision of VR86. Remember, VR86 is not an interesting part of the
domain. It is just there to remember the name "A". The question then
becomes, how does the user know that this is the case? Some people may
wrapper their resources when building configs. Some may not. It is
bothersome that there is no way to indicate if something has been
wrappered or not.
Another way to look at this is to say that configurations always form a
local root. Revisions directly added to the configuration (e.g.,
VR7.R23) logically fall under that root and so have a name (e.g., "A").
This seems to have a natural analog to filesystems that users might
expect.
Fundamentally, the mechanism for which I argue is the same as your
suggestion (user wrapping of "roots") except it is done
automatically/transparently by the server for every configuration. It is
consistent. Remember, I am of course free to ignore any of the names
indicated directly or indirectly by a configuration when mounting this in
user URL space.
The difference is subtle but (IMHO) is worth considering. This approach
gives users a starting point in that they know some name for the "root"
resources and they know all of the root resources are "real" (i.e., not
just there to maintain namespace). It also eliminates the requirement
for clients to create/maintain these extra collections which are not part
of their domain.
> SUMMARY
> =======
> Overall I vote for Sets with the ability to maintain root
> names in some
> standard way. I do not have to use then when mounting a
> configuration
> but it sure would be nice to have that starting point. If
> we are really
> hot about putting individual revisions into a
> configuration, use the
> versioned-resoruce id as the name and the revision-id as
> the value on a
> regular collection put operation.
>
> I don't think it is meaningful to talk about "maintaining root names"
> of a configuration (except trivially by adding a versioned-collection
> revision that that gives them names, in which case they are
> no longer roots).
They are the *real* roots to the user. The fact that they were forced by
the DAV protocol to create this other versioned-collection just to
maintain their names is an annoyance. Its like having to create / on
your floppy when you want to copy files to it. Users expect it to just
be there.
> BTW, we still need to talk more about "required/needed
> configurations".
>
> If we have "configurations" (which can have more than one root), then
> there is no need for required/needed configurations. And recently,
> I have become convinced that in any case, it is sufficient to have
> required/needed *activities* to handle the relevant scenarios.
>
> A topic for next week (:-).
Have required/needed activities been written up somewhere?
Jeff