Re: FWD: Questions on the 02 versioning
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Fri, 13 Aug 1999 18:44:05 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Aug13.183400.1250.1288432@otismtp.ott.oti.com>
Date: Fri, 13 Aug 1999 18:44:05 -0400
Subject: RE: FWD: Questions on the 02 versioning
Guess I'll be <jm>
Note: Some shrinkage may have occurred in shipping...
> 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...
>
> 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>
<jm>If / is a versioned-collection then I can't have any non-versioned
resources in my server. This is likely too restrictive to be practical.
If / is not a versioned collection then to find ALL conflicts (i.e.,
every conflict in my workspace) I need to specify / in my REPORT request.
We then need to spec what happens when you hit non-versioned
resources.</jm>
> 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>
<jm>I don't see the value add in this. What is the use-case for why we
need/want this? If I read your (gmc) description right, the activity
list for a config will/could be huge. Every activity involved in the
line of descent of the selected revision of every resource in the
configuration will be technically "in" the configuration!! What did I
miss?
Also, does one explicitly add an activity to a configuration? How? Are
activities implicitly added by virtue of adding a revision who's line of
descent goes through the activity to the configuration?
</jm>
> 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>
<jm>Alternatively, MKRESOURCE "config" at / would put it in the server
defined place and return the URL for where it put it. This is the
"default". Users can spec a different Request-URI (other than /) if they
are really keen. BTW, do we have any use-cases in which users really
want their configs mixed with their domain resources?
BTW, where do baselines go? These are effectively config constructed by
the system when you do a deep CHECKIN. Presumably they have a URL as
well?
I'm very uneasy about all of this. Configurations really are metadata.
They are not content or structure. They are configuration management
info. If we start mixing metadata resources with domain resources, it
significantly muddies the user view? There should be a "meta" area of
the URL namespace where one can escape the domain and access configs,
workspaces, activities, ... We can do better than the filesystem.
</jm>
> 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>
<jm>To be clear. If the needed-configs are actually added to the RSR
then I can edit the RSR and remove one of the needed-configs. How does
this affect the config which needed config I just removed? It may be
better to say that the needed-configs of a config in an RSR are
*implicitly* added to the RSR.</jm>
> 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).
<jm>If I read gmc right, we want to autocreate "sub-baselines" and add
them as needed-configurations on the parent baseline? If so, I agree.
If not, I missed something</jm>
> 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>
<jm>I'm with jra on this one. Seems inconsisent to return errors in some
create cases and not in others. In fact, if we don't then MKCOL would
fail but MKRESOURCE "collection" could succeed (unless special cased in
the spec).</jm>
> 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>
<jm>This is really what I was asking. As I am doing examples for
MKRESOURCE I was hoping to put actual strings in the text.</jm>
Jeff