Next message: Juergen Reuter: "Re: draft-ietf-deltav04.5 now available"
Message-ID: <53803ECFD77B0148A3D834341960E9FA4F8DBF@red-msg-18.redmond.corp.microsoft.com>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <geoffrey.clemm@rational.com>, ietf-dav-versioning@w3.org
Date: Mon, 15 May 2000 11:37:12 -0700
Subject: RE: draft-ietf-deltav04.5 now available
- 3.3: I don't think we should do this -- it will impact
down-level clients by seeing a type they don't understand.
We should add a new property to indicate it is versioned.
A versioned resource is only seen by a client if it explicitly
specifies "versioned-resource" in a Target-Selector header
(otherwise it sees a revision or a working resource).
So a down-level client will never see a resource whose type
is DAV:versioned-resource
[CK] OK, we should make this more clear
- 3.3.4: It isn't "linear" -- it is exclusive/non-exclusive
or reserved/un-reserved that we are talking about.
I think DAV:linear is still useful (if you don't want to
allow any branching), but this is different from exclusive/
non-exclusive (which doesn't prevent branching).
[CK] I'm fine with that
- 3.4.3: I wish we could separate the linear successor from
the merge successors.
- 3.4.4: See 3.4.3
- 3.5.2: See 3.4.3
You can determine which is the successor on "the same branch"
(if any) by seeing which successor has the same DAV:activity.
Similarly for seeing which predecessor is on the same branch.
[CK] Not if I don't support activities -- I believe they
are independent from branches
- GENERAL: The examples should be more realistic (better headers, etc.)
Tim is preparing a detailed "scenarios" document, in which we'll
have realistic examples. So I think "minimalistic" examples in
the core spec are OK.
[CK] I think the final draft (call for comments) needs to
have "full" examples.
- 6.1: It seems wrong to be able to make a resource versioned if
someone else has an exclusive lock on it.
The VERSION request does not change the body or dead properties of a
resource, but I suppose you could make the case that it causes the
request URL to be associated with a different resource, although to a
versioning unaware client, it doesn't look like a different resource.
[CK] Personally, I'd prefer to see an exclusive lock block everything
- 6.3: It seems wrong to allow a checkout of an exclusively locked
item. Some clients may not be able to deal with this and the
changes will be lost. We should at least have an option to fail
if locked, maybe?
How would clients not be able to deal with this, and how would changes
be lost? It is true that you won't be able to checkin your changes if
it is exclusively locked, but a client that cares about this can just
ask for its own exclusive lock before checking out.
[CK] If my client doesn't understand branching, they can CHECKOUT,
but they cannot CHECKIN, right?
- 6.3: We should have a body for the request... to allow the user
to indicate reserved/unreserved, etc.
E.g. a DAV:checkout element?
[CK] Yeah...
- 6.4: We should have a DAV:checkout tag that wraps the body so that
we can more easily add new tags.
I assume you mean a DAV:checkin element? (6.4 is on CHECKIN)
[CK] Yup...
- 6.5: What does it mean to delete a working resource? Is this an
"UNCHECKOUT"?
6.5 is the UNCHECKOUT method definition, but an UNCHECKOUT both deletes the
working resource, and updates the DAV:working-resource-id-set on the
appropriate versioned resource and revision.
[CK] Yes, but what if you use DELETE and identify a working resource?
- 6.6.2: This doesn't feel like it should be required for core? Is
it optional?
No, it's required. It's a very simple recursive routine (probably 10
lines or so), and it's what gives us our general history reporting
capability. It's fine for a particular implementation to provide some
specialized forms of this report that it optimizes, but I think a more
generalized report that is universally available is essential.
[CK] I think this could be more than "10 lines" of code for some servers.
In some cases, "recursion" isn't a preferred approach.
- 7.1: In reading this it is really wierd to make a workspace a
versioned resource. I understand the desire to re-use concepts,
but it is strange that I "checkout" a revision of a versioned
resource and get a versioned resource not a working resource.
You do get a working resource. It's like a normal resource such
as an html document. You start with a "versionable" html document,
and after you put it under version control, you can check it out to
get a new "working" html document. You can then check that in to
get a new "revision" of that html document.
Analogously, you start with a "versionable" workspace, and after you
put it under version control, you can check it out to get a new
"working" workspace. You can then check that in to get a new
"revision" of that workspace.
Note though that you usually would use the "DAV:keep-checked-out"
flag when you CHECKIN a workspace, so that you can continue to use
the same workspace.
[CK] But they are different. I create a workspace and get a
working version. The methods issued do not parallel each
other. This feels really confusing. Why don't we just add
a few new methods and make it simpler to understand?
I think we should separate Workspaces and Baselines to use different
methods so that the concepts are separate.
Why? A baseline is just a "revision" of a workspace, i.e. it has
predecessors, successors, and is suitable for merging.
[CK] See previous comment
- 7.1: Geoff had asked that we think about whether or not it makes
sense to think of activities as branches. I believe they are
separate. I can evision branches w/o activities as well as a
branch with interlaced activities. I think we should keep these
concepts separate.
What significant benefit would we receive from such a separation? It
does significantly increase the complexity from a clients perspective
to have to deal with this interlacing.
[CK] How do I implement this on a system that allows multiple
activities on a single line of descent? I think this is a problem.
- 8.1: Why wouldn't you initially populate the workspace with
SET-TARGET?
Initially, it doesn't matter, since a MERGE and a SET-TARGET is
equivalent on an empty workspace, but for subsequent requests,
a SET-TARGET will wipe out any existing work from that workspace,
and is therefore less likely to be what the user will want to do.
So it seems simpler to just say that you normally MERGE revisions
into a workspace. But I'm happy either way.
[CK] It seems simpler to me that you always populate a workspace
with SET-TARGET -- no special case initialization code.
- 8.1: Last paragraph: I think this is very complex to require all
advanced servers to support these semantics.
This is the "request workspace" paragraph? We've pretty much said
from the beginning that advanced versioning servers will use
a default workspace to determine the default target. How is this
complex?
[CK] What is complex is having the default workspace pull versions
from multiple different workspaces.
- 8.3: I have a problem with sever merging... I think it is OK for
us to have a method to indicate a client-side merge, but having
the server do merges takes us to a complex place.
How is it complex? If a server is going to support merging at all,
it needs to determine whether two revisions are on the same line of
descent. To say that if they are not, that it creates a working
resource with the appropriate predecessors seems both very useful,
simple to implement, and straightforward for a client to use.
[CK] See below
How can a client
discover what has been merged?
From the DAV:update-set in the response body of a MERGE request.
What if the client doesn't want
the server to do any merge?
[CK] No I mean I want to review the server merge. This means
providing the diff/merge results in a standard way... this
is hard. Your tag only allows for identification of a
resource.
Then it asks for a DAV:conflicts report, rather than a MERGE request.
[CK] But that only identifies the resources in conflict.
I think the MERGE method should be
meta-data only -- not content.
The DAV:merge-state allows the server to say whether it has done
anything to the content or not. So a server that believes that there
should be no server-side content merging would just always return
DAV:initial as the merge state.
[CK] My point is that I want to be able to review the server changes
and even allow blocking server merging. I think this is a very
slippery slope.
- 8.3: Can SET-TARGET cause merge conflicts? This space can be
very messy to do in a fully interopable way.
A merge conflict can only occur as part of a MERGE request, so
SET-TARGET can never cause a merge conflict.
[CK] But if I SET-TARGET from another workspace... isn't that a
conflict?
- 8.5: I'm not sure what is meant by a "versioned collection".
Each revision of a versioned collection is a set of bindings and
properties (as detailed by the bindings protocol).
Does changing the contents create a new version?
If by "contents", you mean the set of bindings owned by that collection,
then yes. Normally, I wouldn't use the term "contents" to refer to the
set of bindings, since some people use the term to mean some server
defined default contents such as an index.html file.
If so, then I think
we need to consider an intermediate level. That is, I should be
able to have a "versioned collection" that tracks its properties
and changes to them, but not necesarrily its children.
If you mean that a change to the state of one of its children should
not change the state of the versioned collection, then I agree.
The state of a versioned collection tracks what resources are
the (immediate) members of the collection, but does not track
the states of those resources.
[CK] My point was that I want to "version" the collection when I
issue a PROPPATCH against the folder, but not when I create
or rename a resource within the collection.
- 9.1.1: Why is this in advanced and not core?
It is in core as well. It was just repeated in advanced because of the
"unification" of labels and workspaces. If we follow your suggestion
and keep labels and workspaces separate, then we wouldn't need 9.1.1
[CK] I didn't see it in the core section -- I'm sure I overlooked it.
- 9.2.2: See previous comment re: merge
Many servers do provide server-side merging support for a variety of
resource types. This property is all that is required to allow a server
to communicate back to the client as to whether it has provided any
such support, so I believe it provides significant value at minimal
cost in complexity.
[CK] See previous comments
- 9.3.7: I'm not sure I understand what this property is for...
This provides a way for a client to enumerate the workspaces that
are expected to periodically MERGE their work to this workspace.
It provides some minimal interoperable support for "change flow".
[CK] This seems like a user annotation. Why do we needs a property
for it?
- 9.4.2: I think this needs to be optional -- I can see server
supporting activities, but this is more complex.
The only semantics here is that when you do a MERGE on an activity, it
invokes a MERGE on all its DAV:needed-activity-set as well. This
seems pretty innocuous, but I'm happy to get rid of this property, if
nobody wants to champion it.
[CK] I think it should at least be optional.
- 10.1: Why don't we fold this header into Target-Selector?
Target-Selector only applies to the request-URL. The Workspace applies
to all versioned resources encountered in the request (primarily used
to deal with versioned collections). This separation allows a
core-versioning client to interoperate with an advanced versioning
server that supports versioned collections.
[CK] That seems a fine line or am I missing something?
- 12.3: It isn't clear how I merge between two workspaces.
You take a revision, baseline, or activity produced in one workspace,
and merge it into the other workspace. You can also just name
the source workspace in the request-URL, and that will merge every
revision in the source workspace into the destination workspace
(named in the Workspace header).
[CK] How do I merge a single resource? It felt like we were missing
a header.
- 13.1: I don't think I understand what this report is for? Is
it required or optional?
This lets you find out what the default workspace is for a URL.
It is required, but it can return an empty element if there is no
default workspace for that URL.
[CK] This goes back to my belief that there should be a single
default workspace, not one per resource.
- 13.2: Can this report be optional?
This seems like a reasonable thing to require that a server provide.
For some servers, this will just be some server-defined munging of
the stable URL. For others, it will require scanning over the
versioned resources in the workspace, but in either case, it is
far more efficient for the server to do it.
[CK] Why isn't this just the stable URL for the resource? Why do
we need a separate report?
- 13.3: Shouldn't this be just like the MERGE method in terms of
the data that can be passed?
The input is the same, but the output is different because the
MERGE method can just create the appropriate set of working resources
whose DAV:predecessors indicate the contributors, while the conflicts
report needs to capture this contributor list as an XML report.
[CK] It felt like you could express more with the MERGE method than
you could here.