- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 11 Jun 2002 11:20:06 -0400
- To: w3c-dist-auth@w3c.org
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