CHECKIN/OUT Protocol Review
jamsden@us.ibm.com
Fri, 15 Oct 1999 14:38:29 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525680B.0066A403.00@d54mta03.raleigh.ibm.com>
Date: Fri, 15 Oct 1999 14:38:29 -0400
Subject: CHECKIN/OUT Protocol Review
Here's my comments on Brad's CHECKIN/CHECKOUT protocol
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.
1.1.2, 1st para: duplicate might want to be mutable copy. Then we don't have to
define what a duplicate means. Similarly, we don't define what editing is, only
modifying a resource or its properties.
2nd para, last sentence: CHECKOUT and CHECKIN are used to enable modification of
a revision, they aren't used to do the modification.
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.
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?
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.
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.
There's also a DAV:current-label (or some such name) that is set, but maybe this
happens on checkin.
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?
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.
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.