RE: checked-out VCC: A new proposal

   From: Fay, Chuck [mailto:CFay@filenet.com]

   Overall, I prefer the previous DAV:auto-version property and its
   settings, because the four possible settings were all well-defined.
   With the proposed property tuple (DAV:auto-checkout,
   DAV:auto-checkin) replacing DAV:auto-version, there appear to be
   thirty-two possible settings of the tuple.

Actually, the four possible values:
 auto-checkout=unlocked-update
 auto-checkout=locked-update
 auto-checkin=unlocked-update
 auto-checkin=locked-update
are independent of each other, so there are no combinatorics involved
here.

Also, separating it into two (independent) properties made the
writeup much simpler (especially when I needed to add a 5'th
alternative to DAV:auto-version).

   This seems like an unnecessary jump in complexity, if all that was
   needed was one more setting for DAV:auto-version, namely
   "always-checkout-manual-checkin".

The comparison here is 5 possible independent values for the
auto-version property, versus 2 (symmetric) independent values for the
auto-checkout and auto-checkin properties.

   (Incidentally, if we go back to the DAV:auto-version property, I
   recommend renaming "DAV:when-locked-checkout" to
   "DAV:when-locked-checkout-when-unlocked-checkin", in order to be
   consistent with the other setting names.  It should cover both
   checkout and checkin explicitly like the other setting names.)

The use of "unlocked" here could potentially be confused with "when
the resource is in the unlocked state" and "when an UNLOCK operation
is applied to the resource" ... but if we don't go back to the
auto-version property, we don't need to deal with these 6 word
"values" (which is one of the things I felt made the auto-version
appear unnecessarily complex).  With the auto-checkout and
auto-checkin properties, simple two word values were sufficient.

   Specific issues with the tuple proposal:

   1. It's not clear to me how the server should behave for some of
   the settings for (DAV:auto-checkout, DAV:auto-checkin), such as
   (DAV:unlocked-update, DAV:locked-update) or (not set,
   DAV:locked-update and/or DAV:unlocked-update).

The behavior of the server with one value is set is independent of its
behavior when another value is set (which is why there is no
combinatorics here).

In particular, auto-checkout=unlocked-update means that when you
update an unlocked (checked-in, version-controlled) resource, it is
automatically checked out before the update.  The value of
auto-checkin has no effect on this behavior.

Analagously, auto-checkin=locked-update says that when you update a
locked (checked-in, version-controlled) resource, it is automatically
checked in if it was automatically checked out for the update.  This
behavior is independent of the value of auto-checkout.  Now it is true
that if auto-checkout=locked-update is not set, then a locked resource
would never have been automatically checked out, but this doesn't
change/affect the meaning of auto-checkin=locked-update.

   2. What is the meaning of the DAV:unlock setting for
   DAV:auto-checkin?  It was listed in the formal definition but never
   referenced in the text.

Oops.  That was a remnant of a rejected earlier approach (which didn't
make it into the working draft, but did get left in the mail message).
There are only 2 possible values for DAV:auto-checkin (i.e.
DAV:locked-update and DAV:unlocked-update).

   3. The description of the checkin-on-unlock operation doesn't seem
      complete.

   Geoff Clemm wrote:
   > If a write-locked version-controlled resource was automatically
   > checked out because the DAV:auto-checkout property was
   > DAV:locked-update, a removal of the write lock (such as from an
   > UNLOCK or lock timeout) is automatically preceded by a checkin
   > operation.

   Another clause concerning the setting of DAV:auto-checkin seems
   necessary to make the above statement true:

   "If a write-locked version-controlled resource was automatically
   checked out because the DAV:auto-checkout property was
   DAV:locked-update, and the DAV:auto-checkin property is
   DAV:unlocked-update and not DAV:locked-update, a subsequent removal
   of the write lock (such as from an UNLOCK or lock timeout) is
   automatically preceded by a checkin operation."

Good point!  How about the following phrasing though:

If a write-locked version-controlled resource was automatically
checked out because the DAV:auto-checkout property was
DAV:locked-update, and if the resource was still checked-out when the
write lock is removed (such as from an UNLOCK or lock timeout), then
the removal of the write lock is automatically preceded by a checkin
operation.

   Again, however, I would prefer extending the simpler
   "DAV:autoversion" property over resolving these issues with the new
   tuple proposal.

I did try to just extend the DAV:auto-version property with this new
value, but it made the precondition and postcondition texts rather
incomprehensible, while the DAV:auto-checkout and DAV:auto-checkin
based text works reasonably well.

So if it is just a preference, rather than an objection, I'd like
to go forward with the auto-checkout/auto-checkin properties
(but feel free to reraise the objection after you see the result
in the working draft).

Cheers,
Geoff

Received on Tuesday, 17 April 2001 23:34:57 UTC