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