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

RE: auto-checkout and auto-checkin

From: John Hall <johnhall@evergo.net>
Date: Wed, 11 Jul 2001 22:15:06 -0700
To: "'Lisa Dusseault'" <lisa@xythos.com>, "'DeltaV'" <ietf-dav-versioning@w3.org>
Message-ID: <001101c10a91$9df48cf0$0400a8c0@xythosjohnhall>
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

Consider PUT.

The code becomes:

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.

Checkout-unlocked and Checkin-unlocked imply and atomic operation.
'PUT' becomes equivalent to 

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

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

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

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Lisa 
> Dusseault
> Sent: Wednesday, July 11, 2001 9:41 PM
> To: DeltaV
> Subject: auto-checkout and auto-checkin
> I used to think I understood what the auto checkin/checkout 
> stuff did, and meant.  Now I think I don't.  The latest 
> changes to that section of the spec (might have been a while 
> ago) actually made it harder to handle.
> 1.  If I read the definition of auto-checkout, it's pretty 
> clear the checkout is triggered by a modification request, 
> but whether the trigger happens is dependent on the _state_ 
> of the resource.  Thus "unlocked-update" means "if the 
> resource is unlocked when the trigger event happens, do a 
> checkout".  But then the definition of auto-checkin is not 
> the same.  I would have thought "unlocked-update" meant "when 
> the resource is unlocked do a checkin", but that's different 
> than the definition of auto-checkout.  At any rate, whether 
> the tags mean the same thing in both properties is one 
> problem, but what both tags mean for auto-checkin is the real 
> problem.  The missing piece of information for auto-checkin 
> is what requests TRIGGER the auto-checkin behaviour.
> 2.  Is it really reasonable for a server to have 
> unlocked-update, but NOT locked-update?  Currently the spec 
> allows either value, both or neither. This is a total of four 
> states the client must understand.  One can be eliminated.
> 3.  Is it really reasonable for a server to have auto-checkin 
> behaviour but no auto-checkout behaviour?  E.g. have a 
> auto-checkin with "unlocked-update" but auto-checkout shows 
> nothing?  If it's not reasonable, then 3 additional states  
> can be eliminated without the client having to worry about them.
> On the whole, I preferred the automatic checkin/checkout 
> stuff the way I remember it - there was less combinatorial 
> confusion, there were no unreasonable settings, and the 
> explanations were clearer.
> Lisa
Received on Thursday, 12 July 2001 01:15:10 UTC

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