Re: CHECKIN/OUT Protocol Review
Bradley Sergeant (Bradley.Sergeant@merant.com)
Tue, 19 Oct 1999 14:56:11 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF53438BC@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: ietf-dav-versioning@w3.org
Date: Tue, 19 Oct 1999 14:56:11 -0700
Subject: RE: CHECKIN/OUT Protocol Review
Jim and Geoffrey,
Sorry for the delay in responding. Friday through Monday I was offline.
There is a use case for recursive CHECKOUT and CHECKIN. If a widespread
change needs to be made through out a web site it can be much more efficient
to do so on the server without the round trips needed for each resource.
This is not the case if you are doing individual edits. It is the case if
you are updating properties across a web site. With recursive
CHECKOUT/CHECKIN you can then do:
CHECKOUT
PROPFIND
CHECKIN
to, for example, change a property value containing the name of the company
that has changed names. Because PROPFIND is recursive you only need three
round trips to get this done. This is efficient if you know that all or
most of the resources selected really need the update.
Supporting recursive CHECKOUT/CHECKIN does add complexity to the protocol.
It's a trade-off. Let's see if there's any demand for it as the spec is
reviewed.
--Sarge
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Friday, October 15, 1999 2:42 PM
To: ietf-dav-versioning@w3.org
Subject: Re: CHECKIN/OUT Protocol Review
From: jamsden@us.ibm.com
Just a general reaction: this seems somewhat more complicated than any
other checkout documentation I remember reading on any product I've
ever used. Perhaps we should look for ways to simplify this method.
I believe one of the problems is that the descriptive text of this
method (i.e. text preceding the Preconditions section) repeats
information that is specified in the earlier sections of the protocol,
as well as definitions of terms from the terminology section. I
suggest we replace the text preceding the "Preconditions" section with
simply:
"The CHECKOUT method can be applied to a versioned resource to produce
a working resource. This working resource is a modifiable copy of the
current target of that versioned resource."
1st precondition: has to be a versioned collection, and server must
support versioned collections or the method will fail.
3rd precondition: one can checkout an empty versioned collection in
order to add members. You can't checkout a collection that isn't
versioned. This (and other statements) sounds like the only reason to
checkout a collection to checkout all its members. Depth 0 couldn't
mean this, it means checkout the collection, which must be
versioned. Depth 1 and infinity must checkout the collection as well
as its members, just like other depth operations. However, I don't
think we need to support depth on checkout of collections. I don't
think there is a use case for it.
I agree. Checking out a versioned resource that is a collection
(i.e. a versioned collection) just means checking out that collection.
Checking out a member of a collection is a different (and separate)
operation.
Doesn't the DAV:coparms element specify a set of preconditions that
the user expects to be valid at checkin and wants to verify
proactively at checkout? Shouldn't these be described in
preconditions for checkout as the method will fail if these conditions
can't be met?
That sounds right.
Ok, I see the second paragraph of the semantics section clarifies the
use of the depth header on collections. The previous sections seemed
to mislead me. The last sentence of this paragraph should indicate the
collection is checked out too. So this seems to be an overload of
checkout on a collection. You can checkout an unversioned collection,
but it doesn't actually checkout the collection, only its members. Do
we need this? Do we really think users need to checkout all the
members of a collection in a single method? Especially with depth
infinity?! I don't recall a product that does this. Checkout is
conceptually an expensive operation as it implies modification
followed by checkin, and has an effect on resource availability. It
doesn't seem to make sense to make it so easy to checkout so many
things at once.
I agree.
Postconditions, if the DAV:activity property is not defined on the
Current workspace, I didn't think a server supporting activities had
to assign one to the new working resource. The activity could be the
null activity couldn't it? This was one of the things we needed to
make servers that support activities consistent with clients that
don't use them. That is, servers that support activities are backword
compatible with those that don't.
I think what we need to say here is that a server MAY fail a checkout
if no current-activity is set. This is very important for servers that
don't want to randomly create activities for clients. A server
certainly MAY automatically create an activity (or pick an activity)
to improve interoperation with non-activity clients, but I don't think
we should require it to do so.
There's also a DAV:current-label (or some such name) that is set, but
maybe this happens on checkin.
Yes, that's a CHECKIN thing.
Results Marshalling, second bullet: does a working resource have a
revision id? Doesn't the revision id get set on checkin? The working
resource isn't quite a revision yet, or is it?
The revision id gets set on checkin ... the revision-id that Brad
is talking about here is the revision-id of the revision being
checked out. I'm inclined to suggest we not load this kind of
information in the checkout response.
Don't some of the status codes like 201 and 409 have to be returned in
a multi status in order to get the DAV:coresults elements? In the
example, a DAV:response element is the document root element. I think
the DTD for WebDAV shows similar respons elements as members of a
DAV:multistatus element.
I believe that is correct.
The DAV:coparms were never used during the checkout except to set some
initial values in the working resource properties. I thought they were
specified on checkout to have the checkout fail if the expected
checkin was likely to fail. Otherwise these are just parameters on
checkin, and have nothing to do with checkout or the working resource
and there's no reason to specify them here, or save them in the
working resource.
Some of the coparms just tell the server what the checkin behavior of this
working resource should be. One way to think about CHECKOUT is that it
is the creation routine for a working-resource, and some of the properties
of the working resource indicate what the checkin behavior of that working
resource will be.
Cheers,
Geoff