Re: CHECKIN/OUT Protocol Review

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 15 Oct 1999 17:41:51 -0400 

Date: Fri, 15 Oct 1999 17:41:51 -0400
Message-Id: <9910152141.AA20201@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525680B.0066A403.00@d54mta03.raleigh.ibm.com>
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