W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: auto-checkout and auto-checkin

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Thu, 12 Jul 2001 12:31:26 +0100
To: "'DeltaV'" <ietf-dav-versioning@w3.org>
Message-ID: <OFD8E0EB2C.331C7E74-ON80256A87.003DE79C@portsmouth.uk.ibm.com>

"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...
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

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

> 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:
> 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).

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC