Re: FWD: Questions on the 02 versioning protocol draft
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 13 Aug 1999 17:30:18 -0400
Date: Fri, 13 Aug 1999 17:30:18 -0400
Message-Id: <9908132130.AA26162@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <9908131834.AA26062@tantalum> (gclemm@tantalum.atria.com)
Subject: Re: FWD: Questions on the 02 versioning protocol draft
Following Jim's admirable example, I'll use <gmc> ... </gmc> tags to
delimit my comments.
From: jamsden@us.ibm.com
Good set of questions. Comments in <jra> tags below...
Jim Whitehead, see the comments on MKRESOURCE and PROPPATCH below.
Jeff_McAffer@oti.com (Jeff McAffer OTT) on 08/11/99 02:29:13 PM
I writing up the REPORT method and making an example for MKRESOURCE I
came up with a fair number of questions...
1) are compare and conflict reports deep? That is, if the specified
resource is a versioned collection, does the report include all
transitively reachable resources?
<jra> The conflict report applies to resources (and collections)
visible in the current workspace. So this indirectly implies the
reports are deep, but that is not really the point. </jra>
<gmc>
I agree with Jim's conclusion (i.e. that conflict reports are
deep), but I don't think it necessarily follows from the fact that the
conflict report applies to resources visible in the current workspace
(for example, resources that are visible in the current workspace but
are not members of the specified collection would not appear in the
conflict report). I'm not sure what Jim meant by "that is not really
the point".
To make this clear, I propose that we add to the Conflicts
report section:
"If a conflicts report describes the conflicts for a versioned
collection, and the specified workspace selects a particular revision
of a versioned collection (i.e. there are no conflicts for that
versioned collection), then the conflicts report is implicitly
extended to request conflicts for all members of that versioned
collection."
OK, maybe it doesn't make it "clear", but some words to this effect
are in order (:-).
</gmc>
2) If #1 = yes, when we hit a non-versioned resource during the
traversal, what happens? I suggest that the report not report on
non-versioned resources.
<jra> There can't be conflicts with unversioned resources because they
only have one revision, and therefore it is impossible to have
conflicting revisions. This isn't really a special case, but a base
case. </jra>
<gmc> If we keep the restriction in the current spec that
"versioned collection members must be versioned resources"
(something I advocate), then this case does not arise. </gmc>
2.5) If #1 = no, why? How would I, for example, find ALL conflicts.
<gmc> We could use the "depth" header here, but if we do, I propose that
the default be "depth=infinity". </gmc>
3) Observation: if conflict reports are transitive then when we hit a
versioned collection which is ambiguous (i.e., a conflict) the report
cannot continue the traversal of its the collection's children as it
is ambiguous which set of children should be followed.
<jra> The report can continue by using the first selection from the
workspace to derive additional conflicts. This may create conflicts
that are uninteresting, and will require the user to get the report a
number of times while resolving conflicts because some of them may go
away as the result of incremental resolutions. I think this is
expected though and impossible to avoid. </jra>
<gmc> I believe (and the suggested wording above states) that the report
should terminate at the first conflict. </gmc>
4) sections 5.2.2.2/5 talk about having activities in configurations.
This is confusing. What does it mean to have an activity in a
configuration?
<jra> An activity in a configuration says select the latest version in
that activity, just like it does in a workspace.
<gmc>
The meaning of "an activity being in a configuration" is related
to, but significantly different from, the meaning of "an activity
being in a workspace" (more accurately, "an activity being in the RSR
of a workspace").
If an activity is in an RSR of a workspace, this means that the
*latest* revision of that activity is on a line of descent to the
revision selected by the workspace (or there is a conflict).
An activity being in a configuration is a report on whether the
products of that revisions in that activity are "included" in that
configuration. More formally: "An activity is in a configuration if
at least one revision that is a product of that activity is on a line
of descent to the revision selected by the configuration." It can be
the case that only part of an activity is in a given configuration.
This is how an activity can have "changed" from one configuration to
another, as indicated by the "DAV:changed" element. Unlike a workspace,
there are never any "conflicts" in configuration revision selections.
</gmc>
A configuration could
be viewed as a persistent workspace, or a convenience for capturing,
recovering, and/or reusing revision selection rules (perhaps more than
one, one for each configuration) in a workspace. In this case, the
revision selector is floating, so the configuration won't select the
same revision all the time. That's not what configurations are
generally used for, but I don't see any reason whay we should rule it
out. </jra>
<gmc> There is no association of revision selection rules with
configurations, so there is no way that a configuration could float
to track the changes in an activity. The functionality required
to do this kind of floating is something that only a workspace would
provide. </gmc>
5) how does one create a configuration? MKRESOURCE is the likely
candidate but it is expecting a Request-URI. What is this supposed to
be? Is it possible to have MKRESOURCE return a URL in its response
body?
This would allow servers to put configurations wherever it wanted
them and tell users where they were. Alternatively, the only way to
make a config is to deep check-in a collection and then access its
baselines property. This seems circuitous and reduces the usefulness
of MKRESOURCE. Note that I am looking at configurations as "metadata"
which should generally not appear in the normal user URL space.
<jra> Users create resources where they want them. Configurations are
user resources, so they should specify the URLs. If the server needs
to have all the configurations in one location for its purposes, then
it should use links to hide this implementation detail. So I don't
think of a configuration of metadata that doesn't belong in the user
URL space. They are user resources, not server resources. </jra>
<gmc> I agree.
A particular server could restrict the location of configurations to a
certain subset of the URL space, so we should probably make sure that
one of the failure status codes on MKRESOURCE indicates "cannot make
this kind of resource here" and maybe even "but you could make it over
there". </gmc>
<jra>
We talked about having PROPPATCH be able to create resources and
eliminating MKRESOURCE. This should be discussed on the mailing
list. </jra>
Let's make this a separate thread (best not to mix it in with this
already full thread, though :-).
6) How does one add something to a configuration? That is, what
method with what headers/body should be used to get VR45.67 (revision
67 of versioned resource 45) into a configuration? Similarly, how is
the currently selected resource at http://foo.com/index.html added to
some configuration?
<jra> Here's what was in my notes:
"The current protocol does not specify a method for adding or
removing a revision to/from a configuration. Consider using BIND to
put a revision in a configuration. The BIND puts an entry in the
DAV:roots property and puts the selected revision in the
configuration. Putting a collection into the configuration recursively
puts all its members into the configuration but only adds one entry to
the DAV:roots." We talked about configurations being a specialization
of collection, but that had problems. An alternative is to have it be
a resource whose contents are defined by an XML DTD defining its
members. Adding and deleting members would be editing the contents
with GET and PUT. This would also define the meaning of GET and PUT
which are also not currently defined for configurations. I suggest we
take this approach with all resources where WebDAV defines the
contents and resource type. (note an API could implement editing
collections in very different ways if desired.) </jra>
<gmc> Configurations can be *very* big. I believe an incremental
add/delete protocol is preferable to one that involves locking the
configuration, inhaling the entire state of the configuration, editing
it, putting it back on the server, and then unlocking it. So I
support the BIND approach. I'll try to whip up some wording to this
effect for the spec, so we at least have a placeholder for this issue.
Currently, I'm inclined to just say that a BIND of a versioned
resource to the DAV:roots collection has a side effect of adding the
target of that versioned resource to the configuration. </gmc>
7) What are the semantics of the DAV:needed-configurations property of
configuraions? Are these needed configs transparently traversed by
the workspace if the parent config is (indirectly) in the RSR? Do I
have to manually add to the needed configs? If so, how do I do that?
If it is a collection, what are the member names? If not, then what?
Is it auto-gen'd at deep checkin time? If that is true, then how does
the server detect that some child (of the root being checked in) has a
config that should be put in the needed list? Is it possible ot have
a baseline of this child automatically created? How does this
interact with the DAV:auto-version revision property?
<jra> Dependent configurations (and dependent activities) are
automatically included in the workspace RSR when their source revision
selector is included. You don't have to add them. The members of a
collection are determined by applying the workspace revision selection
rule, just like any other resource. </jra>
<gmc> I agree. There is no special interaction with DAV:auto-version
or CHECKIN. </gmc>
I suspect that this is an orthogonal concept and that we need another
property on collections which says whether or not they should be
baselined if a parent is being baselined and they have (transitively)
changed since the last baseline.
<jra> I think a baseline of a member collection of a parent collection
is independent of baselines of its parent. When the parent is
baselined, the selected revisions of its members are added to the
resultant configuration. A child collection can then have a baseline
of its own which results in an entirely different and independent
configuration with perhaps very different revisions selected. </jra>
<gmc> I go the other way. A baseline of a versioned collection must
contain all the members of that collection (to an arbitrary depth).
So creating a baseline of a collection creates sub-baselines of any
sub-collections that are baselined. Something I would support would
be a property on a versioned collection revision that says whether a
baseline of a parent collection should contain a baseline of that versioned
collection or a revision of that versioned collection (and its members).
8) The MKRESOURCE description is confusing in its treatment of
existing resources. As I understand it, any existing resource is, by
default, deleted and the new resource put in its place. If the
overwrite header is specified, the existing resource is somehow
morphed into the resource you want? The last two paras of the section
are contradictory. One says there are no interactions but the
existing resource is delete (an interaction if you ask me) and the
next says that the existing one is not delete but morphed (i.e., an
interaction but not a deletion).
<jra> I hope we stay away from morphing as it is likely to be
resource-type dependent and therefore not easily
extensible. MKRESOURCE is used to create new resources and should not
overload DELETE. Perhaps MKRESOURC when the resource exists, like
MKCOL, should return an error and then the user can decide if DELETE
followed by MKRESOURCE is appropriate. </jra>
<gmc> I'm fairly neutral on the morphing issue. I don't see how it
being resource-type dependent makes it not easily extensible, but I
don't have a pressing need to morph (or rather, I have alternatives
to morphing). I would just strike the last section that says that you
can morph a versioned resource into a repository. </gmc>
9) What resource types can be created with MKRESOURCE? What are the
actual resource type names for our new resources (configuration,
versioned resource, versioned collection, etc.)?
<jra> Should be able to create any resource type by setting its
DAV:resourcetype property along with any other necessary
properties. </jra>
<gmc> I agree. Note: Some day we need to complete the action item in
the spec that says to pick particular values for DAV:resourcetype for
the new resource types we are creating (the values are pretty obvious,
but we should make it explicit). </gmc>
10) The use of the history-uuid property is not clear. Is it a GUID?
Could/should it be something simpler like a repository-relative id
(i.e., why is it itself universally unique)?
It was intended to be a GUID, but we should discuss this. (It's related
to the other thread Jeff started about returning the revision GUID after
a GET).
Cheers,
Geoff