Re: CHECKIN/OUT Protocol Review

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 19 Oct 1999 23:15:01 -0400 

Date: Tue, 19 Oct 1999 23:15:01 -0400
Message-Id: <9910200315.AA22016@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <F3B2A0DB2FC1D211A511006097FFDDF53438BC@BEAVMAIL> (message from
Subject: Re: CHECKIN/OUT Protocol Review


   From: Bradley Sergeant <Bradley.Sergeant@merant.com>

   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. 

I assume you meant "PROPPATCH"?  But PROPPATCH is not recursive.  It
only affects a single resource (multiple properties, but on the same
resource).  Since you need to do a separate PROPPATCH or PUT to update
the resource, doing a CHECKOUT/PROPPATCH/CHECKIN is only a constant
factor more expensive than just doing a PROPPATCH.  On the other hand,
the cost of unnecessary CHECKOUT's and UNCHECKOUT's can be very
significant.

But more significantly, if you do the batch CHECKOUT first, you are
blocking everyone from doing any work (e.g.  on a totally different
property) on any of these resources until you are done.  This
significantly increases work interference, which is very much not
something we want to encourage.

   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.

Fair enough.  We have to make sure that the benefit/demand exceeds both
the protocol complexity cost and the client penalty (i.e. with increased
lockout).