RE: Comments regarding locking & auto-checkin...

Hi,

Thanks John, you are right, the automatic check-in is fine.
Another issue which was raised at the London IETF was what would
happen if the CHECKIN failed perhaps because forking properties
would disallow it?  And also I raised a question asking if a more
explicit error code should be returned when an If header specifies
a lock which has timed-out rather than an invalid lock, I believe
that at the moment a client cannot tell the difference.

Regards,
Peter Raymond - MERANT.

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: 09 August 2001 17:44
To: 'Peter Raymond'; ietf-dav-versioning@w3.org
Subject: RE: Comments regarding locking & auto-checkin...


I believe that the current behavior is the desired and expected
behavior.

When Fred LOCKS the document and starts working on it, he knows very
well that each and every change he makes is seen by everyone
immediately.  The fact that it is then checked in because he went to
lunch would not seem to be a problem.  At worst he just has more
versions in the version history, but no versions that he didn't intend
to make available.

Now the client program, if continuously operating, should be refreshing
the lock.  If it isn't, then when it is restarted I assume it needs to
check if the lock exists and reaquire it if not.

The worst case is that if the client wasn't written with this in mind,
it will just start doing PUT's with an invalid IF header lock token.  

Is a PUT supposed to be rejected if the IF header provided specifies an
invalid lock token and the resource is not locked?



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Peter Raymond
> Sent: Tuesday, August 07, 2001 4:03 AM
> To: ietf-dav-versioning@w3.org
> Subject: Comments regarding locking & auto-checkin...
> 
> 
> 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 Sunday, 12 August 2001 06:44:54 UTC