Next message: Tim Ellison/OTT/OTI: "Working resource ids"
Date: Thu, 18 May 2000 00:44:30 -0400 (EDT)
Message-Id: <200005180444.AAA05133@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: draft-ietf-deltav04.5 now available
From: Chris Kaler <ckaler@microsoft.com>
- 3.4.3: I wish we could separate the linear successor from
the merge successors.
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
Activities were designed to simplify clients by providing a single
concept that allows them to deal with branching and change-set based
servers in a uniform way. What functionality do you require to
support branching that is not currently provided by an activity
resource?
- 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.
A set of "full" examples could double the size of the protocol
document. So although I agree that a set of full examples is required
as an accompanying document to the final call draft, I believe that
bundling them into the protocol document could decrease acceptance and
review of the protocol document.
But perhaps we are defining "full examples" differently.
- 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
Could you provide some rationale for that preference? I assume you
don't want it to block read access to the resource? What about other
"value preserving" operations such as "compressing" the resource?
I believe a write lock is there to ensure that someone else doesn't
introduce a change that could be lost by a subsequent update. Putting
something under version control (or compressing the resource) does
not introduce such a change, and therefore I don't see why it should
be prevented by a write-lock.
- 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?
Tim suggested that we add a parameter to CHECKIN that says "do not
make the new revision be the default target". I think he's right, and
I believe your point here is an example of why. I've added a
DAV:private argument to CHECKIN to provide this behavior, so this
would allow a client to checkin a change even if there is an exclusive
write lock preventing a change to the "default target".
- 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...
Done.
- 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...
Done.
- 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?
A DELETE actually modifies the collection containing the request-URL
(i.e. by removing the specified binding). Since you only get at a
working resource by operating on a versioned resource whose target is
that working resource, the DELETE actually removes a binding to the
versioned resource. If that is the only binding to that versioned
resource, then that DELETE would make that versioned resource
inaccessible (and all its working resources). If it is just one of
many bindings to that versioned resource, then the working resource
would still be available through other bindings to that versioned
resource.
- 6.6.2: This doesn't feel like it should be required for core? Is
it optional?
I believe it should be 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.
OK, I'll write up the 10 lines of code I think are required, and let
you poke holes in it (note: I'm not saying these will be the most
efficient 10 lines of code, but just that they will be correct :-).
In some cases, "recursion" isn't a preferred approach.
One of course doesn't have to implement it as a recursive routine,
but it provides a simple implementation for servers that don't care
about optimizing the query.
- 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.
I'm not sure what you mean when you say you "get a working version".
When you create a workspace, you get a workspace. When you VERSION
a workspace, you are allowed to CHECKIN that workspace to create
baselines (revisions) of that workspace. You can also CHECKOUT
a baseline to get a new workspace.
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.
I'm happy to go with whatever is simpler/clearer, so we just have to
figure out which way is simpler/clearer. Clearly we can marshall it either
way.
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
I don't see that the previous comment addressed the question of
how predecessors, successors, and merging of baselines are any
different from predecessors, successors, and merging of other
kinds of "revisions".
- 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.
Since a line of descent to a revision is a sequence of successors from
the initial revision to that revision, all branch-based systems will support
multiple activities on a single line of descent. Perhaps I'm missing the
problem you have in mind?
- 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.
The MERGE method has to handle the case where the workspace does not
currently select a revision of the revision being merged, so there is
no special case code required to have MERGE be the primary way that
you populate a workspace. On the other hand, saying that you first
populate a workspace with SET-TARGET and subsequently populate it
with MERGE does seem like introducing a special case for initialization.
- 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.
The server (not the client) determines what the default workspace is
for a URL, so the server can (an usually will) associate all URL's in
a particular URL space with the same default workspace.
- 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
I didn't see any complexity arguments below. Perhaps I missed something?
How can a client
discover what has been merged?
From the DAV:update-set in the response body of a MERGE request.
[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.
The standard way to review the merge results is to GET the contents
of the resource and look at it in your authoring tool.
If you want to "diff" the results of the merge with one or more of the
predecessors, you could try the DAV:compare-report REPORT, but it probably
will be a while before we will standardize on the form of that report.
What if the client doesn't want
the server to do any merge?
Then it asks for a DAV:conflicts report, rather than a MERGE request.
[CK] But that only identifies the resources in conflict.
What more can the server tell you if you don't want the server to do
any merge?
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.
I still don't see the issue. You can review the server changes (if any)
by GET'ing the results of the merge. You can block server merging by
not asking it to merge in the first place (or by UNCHECKOUT'ing the
merges that you didn't like). What is the 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?
No. A SET-TARGET just says "ignore what's in my workspace ... just select
what the SET-TARGET argument says to select". If you are doing a SET-TARGET
from another workspace, you are just overriding your workspaces revision
selection by that of the other workspace.
- 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.
Isn't the whole point of a collection resource is to have a set of
members? If you just wanted a set of properties, you would just
create a regular resource. I suppose you could version just the
properties of a resource, and not its contents, or some of the
properities and optionally the contents, but I believe that would add
a significant amount of complexity to a client with little benefit.
- 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?
It's just like DAV:author and DAV:comment ... i.e. it provides a
standard name for a common annotation. I'd be happy to transfer
all these dead properties into a separate document, but I believe
folks have argued that we should have a few of them in the
core protocol.
- 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.
Given how easy this is to implement, I'd prefer to either get rid of
it altogether, or keep it required. Optional things just make
writing clients difficult.
- 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?
Once the Workspace header has selected a particular versioned resource,
it is still often useful to use a Target-Selector header to override
the target selection for the final versioned resource selected by
the request-URL. Tim suggested we marshal this as two clauses in
the Target-Selector header, but several of us thought it would be
clearer to model it as two separate headers.
- 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.
You use a Target-Selector header or a stable URL to merge a single resource.
- 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.
A server can choose to associate a single default workspace with all
URL's that it manages, (and this report will be very easy for such a
server to implement). But some servers will want to expose multiple
workspaces to versioning unaware clients, and therefore will associate
different default workspaces with different parts of the URL space.
- 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?
Since different workspaces will have different URL's that are mapped
to a particular versioned resource, there is no efficient way for a
client to get a URL that identifies the versioned resource without
this 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.
If so, we should fix it. Anything in particular?
Cheers,
Geoff