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 00:40:46 UTC