RE: auto-checkout and auto-checkin

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.

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.

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

OK:
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