RE: auto-checkout and auto-checkin

"John Hall" <johnhall@evergo.net> wrote:

> Well, a server is free to freeze these values.  The server
> doesn't have to let the client muck with them, and if it
> does allow the client to muck with them I assume it could
> enforce whatever combinations it deems reasonable.

Yes, definitely.

> Consider PUT.
>
> The code becomes:
> putEntryStuff();
> doPut()
> putExitStuff();
>
> Where putEntryStuff will throw an exception if the PUT is
> not allowed.
>
> Checkout-Locked, Checkin-Locked:
> Lock, Put, Unlocked is the expected behavior.  Though Lock,
> Put, CheckIn and Lock, Put, Uncheckout behave just-as-if
> the client had done an explicit checkout before the Put.

Assuming you start with an unlocked version-controlled resource...
LOCK, PUT, CHECKIN      and
LOCK, PUT, UNCHECKOUT
Will both fail because the resource will already be auto-checked-in after
the PUT.

> Checkout-unlocked and Checkin-unlocked imply and atomic
> operation.
> 'PUT' becomes equivalent to
> CHECKOUT, PUT, CHECKIN.

Yes (assuming the version-controlled resource is checked-in and not
locked).

> OK:
> Checkout-Locked, ! Checkin-Locked:
> Lock, Put -- is the same as LOCK, CHECKOUT, PUT and the
> system requires an explicit CHECKIN.

What does !checkin-locked mean?  do you mean checkin-unlocked (a.k.a.
DAV:unlocked-update) or that it has no value?

> Checkout-Unlocked, ! Checkin-Unlocked:
> PUT is CHECKIN, PUT and the resource is left in exactly
> that state.

Sorry, your notation is lost on me -- please can you restate it.

> ! Checkout-Locked, Checkin-Locked:
> Now I really don't like this combination.  It introduces
> nastiness like
> "CHECKOUT, PUT, LOCK, UNLOCK", with the spec potentially
> implying that the UNLOCK would require a CHECKIN.  It is
> OK if this state is explicitly ruled illegal, or if the
> Checkin-Locked is defined so that it ONLY comes into play
> if the CHECKOUT was done because of a Checkout-Locked
> action.
>
> ! Checkout-Unlocked, Checkin-Unlocked:
> CHECKOUT, PUT becomes CHECKOUT, PUT, UNCHECKOUT.  That
> doesn't make sense to me, but I was planning on supporting
> it.  Note that it doesn't require a separate test case
> if putEntryStuff leaves the object in the correct internal
> state.
>
> ============================
>
> Of the 8 possible states, 4 are 'obvious' 3 are 'funny' and 1 is a
> really bad idea.  If you retained the current discription (since I think
> it might be easier to describe things the current way) but added the
> restriction that auto-checkin must be the same value as auto-checkout
> that would be OK with me.

There's quite a list, you have to consider the initial version-controlled
resource being locked or unlocked and checked-in or checked-out together
with the combination of valid values (which are DAV:locked-update,
DAV:unlocked-update, both, or none).

I recall Jim W. wrote out the table a while ago (sorry I can't go and look
for it right now).

Regards,
Tim

Received on Thursday, 12 July 2001 07:34:16 UTC