Re: Configurations, sets and collections
Bradley.Sergeant@merant.com
Mon, 19 Apr 99 20:44:00 EST
From: Bradley.Sergeant@merant.com
Date: Mon, 19 Apr 99 20:44:00 EST
Message-Id: <9903199245.AA924580321@SMTPGwy.MERANT.com>
To: Jeff_McAffer@oti.com (Jeff McAffer OTT),
Subject: RE: Configurations, sets and collections
Thanks for the email Jeff, it saved me some work. Your examples demonstrate the
problems with putting paths in configurations. Configurations need to map
VersionedResource IDs to Revision IDs. Paths can change over time. IDs must
not change over time. By sticking to IDs in configurations you allow
configurations maintain their consistency, even while the path names change.
I'm not sure I follow the problem you posed regarding the roots. I may be
missing something. In the example you outlined VR4 is a versioned collection
that is bound to the root path /. So the names of VR7 and VR2 are maintained in
VR4 and cannot be lost. Also, because you have only one root its name can be
arbitrary. What I mean by this is that the server can map whatever path it
likes to this top level collection and the configuration won't care. Rather,
the name of this top level collection is a system configuration, like a servlet
name.
We can play this out a bit and consider multiple configurations partitioning a
tree of versioned collections, each with a single versioned collection at its
root. I believe it simply means that the name of each root is then determined
by a versioned collection in another, higher-level configuration, and at the top
you have "/" or some other arbitrary name.
Does this make sense?
--Sarge
-----Original Message-----
From: Jeff_McAffer@oti.com (Jeff McAffer OTT) at SMTPPOST
Sent: Monday, April 19, 1999 3:00 PM
To: ietf-dav-versioning@w3.org ('ietf-dav-versioning@w3.org') at SMTPPOST
Subject: Configurations, sets and collections
(this got long but you may find it interesting...)
I have a proposal for the configuration problem which actually combines
the two approaches discussed in today's conference call.
Consider the following simple structure in a particular workspace. Shown
are the human URL segments and the versioned resource (VRxx) to which the
URLs map.
/ (VR4)
A/ (VR7)
B/ (VR 6)
index.html (VR 9)
X/ (VR 2)
cool.gif (VR3)
Y/ (VR1)
...
What this structure really implies is that VR4 (/) is a collection
resource which has three named elements, A, X and Y where A => VR7, X =>
VR2 and Y => VR1. Similarly, VR7 is a collection which has one element
such that B => VR6. and so on.
Below is a description of the two proposals for configurations ("sets"
and "collections") in terms of the above example.
SETS
====
The "Sets" proposal said that a configuration was a *set* of resource
revisions. A couple things to note:
- revisions have a property which indicates their versioned-resource.
- "setness" here is based on versioned-resource not revision.
That is, there can only be one entry in the configuration
for a particular versioned-resource.
- As such, the "set" can be seen as a table where a key is a
versioned-resource id and the corresponding value is a revision
id. A given key can only occur in a configuration once.
In the above example, a configuration encompassing A and X (but not /)
would look something like this (where Rxx is a revision id).
VR7 = R23
VR6 = R3
VR9 = R9
VR2 = R12
VR3 = R11
Because VR7 and VR2 are collections and collections map member names to
versioned-resources, the namespace *below* A and X are preserved. That
is, the *relative* path B/index.htm still exists if you can get to VR7.
The configuration roots can be relocated by "mounting" them at some
point in the user URL space (e.g., putting VR7 at /foo/A).
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. 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.
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). I'm not sure if this is DAV server functionality or
something that clients do on their own. I hope it is the former so that
it is standardized and interop between tools is enabled. Opinions?
BTW, it was proposed that new "set" protocol be added. Would it be
reasonable to use regular collection protocol and give the
versioned-resource id as the name and the revision-id as the element when
putting something into a configuration? This avoids having to add
methods etc to the protocol.
COLLECTIONS
===========
The "Collections" proposal said that a configuration was a collection of
revision ids. Being a collection means there must be member names. I
was confused on this and did not really understand what these names would
be. One choice was that they were autogen'd/random. In this case, case
the names don't mean anything so why bother? Just to satisfy some API?
Another choice (as I understood it) was that the names were the URL
fragments relative to the roots. Note that in either case, the values in
the collection are the complete revision ids (including the
versioned-resource id) of the resource revision in the config. For the
example above, the configuration is:
A = VR7.R23
A/B = VR6.R3
A/B/index.html = VR9.R9
X = VR2.R12
X/cool.gif = VR3.R11
Note that the names of VR7 and VR2 are maintained. Unfortunately, there
are problems. First the information is redundant. The namespace,
exclusive of the names A and X, is maintained by the
versioned-collections themselves. This leads to the problem that if I
rename B in A, I have to go and change all the entries in the
configuration. If A is high up in a large configuration, this is
expensive. In the Sets example, you only have to change the revision of
VR7. It does however allow you to maintain the collection protocol for
configurations.
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.
BTW, we still need to talk more about "required/needed configurations".