- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Sun, 12 Aug 2001 20:10:27 -0400
- To: ietf-dav-versioning@w3.org
Peter,
Perhaps it is unfortunate that locking and checking/checkout are coupled
resulting in potentially undesirable behavior on lock timeouts, but this is
an unavoidable consequence of supporting non-versioning, but locking aware
clients. The purpose of the lock is similar to checkout - it indicates a
user intends to modify a resource and protects those modifications from
being overwritten by other users. To maintain these semantics, unlocking,
either by the user using UNLOCK, or the server through lock timeouts, or
any other means (e.g., unlock by another authenticated user) should not
result in lost updates. The consequence of checking in something that isn't
ready for wider viewing on lock timeour is less drastic than having the
changes overwritten by some other user. So I suggest we leave the spec as
is, and users and clients should be sure to use appropriate lock timeout
values.
Peter Raymond
<Peter.Raymond@merant.co To: ietf-dav-versioning@w3.org
m> cc:
Sent by: Subject: Comments regarding locking & auto-checkin...
ietf-dav-versioning-requ
est@w3.org
08/07/2001 07:03 AM
Hi,
Section 3.2.2 when DAV:auto-checkout is DAV:locked-update and a lock
times out the specification
says a implicit CHECKIN operation will happen. This just seems a little
odd.
For example imagine user Fred is sitting in his client application LOCKS
a document and starts work on
it, he takes his time working on the doc and his LOCK times out, so
suddenly his incomplete work will be
checked back in without him knowing. I guess when he goes to unlock the
document (as he is not aware
that his lock was timed out) he would get an error saying something like
"You don't have a lock on this
document (invalid lock token)".
Other options for the behaviour of timed out locks would be:
1) Just cancel his lock (but not auto checkin).
This would avoid checking in Freds incomplete work but would leave
Fred equally confused when he
tries to unlock and is told that he has not got the document
locked.
2) Do not timeout locks for auto versioning clients.
This would keep Fred happy since he keeps the lock but it totally
defeats the point of lock timeouts.
Do any clients set lock timeouts to be anything other than
Infinity? I have not seen any use of lock
timeouts yet.
3) Find some way to inform the client that the lock has timed-out.
Since HTTP is request/response driven we can't just send a message
to Fred to inform him the lock
has timed out (he needs to request something first). So the only
implementation I can think of would
be for the client to send some kinda lock keep-alives.
I guess my preference is for option 1 but when Fred unlocks we should
return some specific error so
at least the client knows that the unlock failed because the token
specified was timed-out (rather than
just an invalid token).
What do other people think? Do lock timeouts actually get used (if not
we should remove them from the spec).
We were talking in the WebDAV (RFC2518) meeting yesterday about allowing
some principal other than the
lock owner to unlock a resource so removing lock timeouts would not mean
the lock is unbreakable.
Regards,
Peter Raymond - MERANT.
Received on Monday, 13 August 2001 16:38:08 UTC