Re: CHECKIN/OUT Protocol Review

Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 20 Oct 1999 11:17:41 -0700 

Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF53438BE@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: ietf-dav-versioning@w3.org
Date: Wed, 20 Oct 1999 11:17:41 -0700
Subject: RE: CHECKIN/OUT Protocol Review

Sorry about the example, I was looking at PROPFIND and thinking PROPATCH.
PROPFIND takes the Depth header and PROPATCH does not.  So there apparently
is no way of doing batch updates.  Some how I had it in my head that there
was.  Too bad.

BTW, there are times where you do want to block everyone out while you make
a key change.  It happens, but I'll grant you it is not the typical case.

--Sarge

-----Original Message-----
From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent:	Tuesday, October 19, 1999 8:15 PM
To:	ietf-dav-versioning@w3.org
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).