RE: [w3c-dist-auth] <none>

In normal practice, you should not be "stealing" lock tokens, even if the
lock token was taken out by another process owned by "you".  You should
leave the resource alone until the process that took out the lock has
released the lock.  In an exceptional case, where the process that took out
the lock has died before releasing the lock (and lock timeouts are not
automatically releasing the lock), you can attempt to "steal" the lock
tokens, but this should be an exceptional case, done only after explicit
confirmation by the user ("yes, I want to override these locks").

Cheers,
Geoff

-----Original Message-----
From: Rajiv A V [mailto:rajiv_av@infosys.com]
Sent: Tuesday, June 11, 2002 11:03 AM
To: w3c-dist-auth@w3c.org
Subject: [w3c-dist-auth] <none>


Hi, 
  I have a very trival issue in the use of lock tokens. reading about the
use of lock tokens from the RFC it seems that a process (user)should be
aware of the resources he is deleting. But let us assume that my client
fetches lock tokens (performs lock discovery) on a need basis. Now assume
that I want to delete a folder resource inside which I have some stuff that
I have locked myself. I have 2 ways to implement it

a) dont delete the resouce since the user hasnt seen the resource yet and
wait for the user to see all the resources that he has locked (effectively
meaning that then he has a lock token for all the needed resources because
thats when the lock discovery is done)
b) when i recieve that detail from the server that tells me that some
resouce is locked, just inform the user that there are locks inside
the folder. then on user confirmation the client would interally fetch all
the lock tokens for resources that are locked inside the folder and goes
ahead with the delete. this would be transparent to the user but the user
knows that he is deleting resources that he has a lock on.

I know this is a implementation issue but please let me know which is the
right way to do it and would be more webdav compliant.

 thanks and regards,
     rajiv

Received on Tuesday, 11 June 2002 11:20:39 UTC