- From: Geoffrey Clemm <geoffrey.clemm@Rational.Com>
- Date: Tue, 10 Aug 1999 13:35:59 -0400
- To: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>, <w3c-dist-auth@w3.org>
The message in WBW gives 4 choices: - fail the move if locks cannot be retained - try to maintain the locks, but let the move succeed even if the cannot be retained - require that locks be retained on a move - disallow a move on a locked file You then voted for the last choice. I'm not sure how this then resulted in the current semantics of "allow the move but strip off the locks". Are there other messages that provide the intermediate reasoning? In particular, I'm looking for a counter argument to: #1 seems to be a preferable choice, since it is trivial for both lock-preserving and lock-losing servers to implement, and a client needs to deal with a variety of failure cases for a move anyway. Having "cannot move locked file" be one of them does not seem much of an additional burden, and it does not force servers that can move locked objects to gratuitously remove all locks, and then have the client add them all back again. Cheers, Geoff -----Original Message----- From: Yaron Goland (Exchange) <yarong@Exchange.Microsoft.com> To: 'Geoffrey M. Clemm' <gclemm@tantalum.atria.com>; ejw@ics.uci.edu <ejw@ics.uci.edu> Cc: w3c-dist-auth@w3.org <w3c-dist-auth@w3.org> Date: Friday, August 06, 1999 1:15 PM Subject: RE: FW: [Moderator Action] Questions on Webdav Servers >Section 7 of the WBOW vAlpha2 >(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html) >point to >http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html which >explains the reasoning. > > Yaron > >> -----Original Message----- >> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] >> Sent: Sat, July 24, 1999 8:39 PM >> To: ejw@ics.uci.edu >> Cc: w3c-dist-auth@w3.org >> Subject: Re: FW: [Moderator Action] Questions on Webdav Servers >> >> >> >> From: Kevin Wiggen [mailto:wiggs@xythos.com] >> >> The following are a few more questions I have. >> >> ... >> >> 3) MOVE/COPY to a destination that is locked. 8.10.5 >> states "... a >> successful DELETE of a resource MUST cause all of its >> locks to be removed." >> and 8.8.4 states that overwrite set to T will do a >> DELETE.... Then will the >> LOCK on the destination be lost?? This seems wrong to me. If the >> destination is LOCKED, then after a MOVE/COPY which might >> delete the >> resource, I would assume the resource is still locked. >> >> I believe that the complexity here is due to the decision to have a >> WebDAV lock be *both* a resource state lock (which means the state of >> the resource is locked no matter what URL you use to access it) >> *and* a URL lock (which means that you have a lock on whatever might >> appear at that URL). >> >> This was done for some very good reasons, since you need both kinds >> of locks to ensure that "when you have the lock, only you can change >> what is at that URL". >> >> Unfortunately, the expected behavior of those two kinds of locks is >> different under MOVE and DELETE, and the current WebDAV semantics ends >> up with (is forced into) a compromise semantics that produces >> counterintuitive behavior from either perspective. >> >> In particular, one would expect a URL lock to be unaffected by a MOVE >> or a DELETE. If you've got a URL locked, you should be able to move >> anything to it or from it (or even delete it, resulting in a locked >> null resource). This I think is the perspective Kevin was taking. >> >> But a resource state lock acts very differently. If you delete a >> resource, the resource state lock should be deleted as well (no state >> left to lock). This is what WebDAV says. But if you MOVE a resource, >> you'd expect the resource state lock to remain in effect. But here >> WebDAV goes with the URL lock semantics and says that a MOVE deletes >> the lock. >> >> Personally, I can live with most of this except for the losing of the >> lock on the move. Can someone point me at something in the archives >> that explains this decision? I didn't find it in Yaron's WBOW. >> >> 4) I assume that a null resource can be created via a URL >> with a trailing >> slash and one without. If I create one with a trailing >> slash, can I only do >> a MKCOL later? If no trailing slash is sent, the server >> probably needs to >> assume that the client might have just not sent the slash >> and allow a MKCOL >> or a PUT. I think the spec should state that a NULL >> RESOURCE can be created >> with a trailing slash or not, AND any NULL RESOURCE can >> take a MKCOL or PUT. >> (You already messed up some of the beauty of my server >> with Null Resources, >> I would hate to put even more if statements in to handle >> the above....) >> >> I agree with Kevin. >> >> Note: These kinds of questions would not arise if >> WebDAV would just state that /foo/x/ and /foo/x always map to >> the same resource (JimW and I periodically go round on this >> one :-). Even Windows and Unix agree that this is >> the sensible approach. >> >> Cheers, >> Geoff >> > >
Received on Tuesday, 10 August 1999 13:36:04 UTC