- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 5 Jun 2001 14:01:33 -0700
- To: "Clemm, Geoff" <gclemm@rational.com>, "DeltaV" <ietf-dav-versioning@w3.org>
It's not "vanishingly small" if you lose your network connection between the MKWORKSPACE and the LOCK request. Or if the LOCK request is lost. Or if the latency is ~2 seconds each way. If somebody who's not supposed to, gets in and changes something inbetween a MKWORKSPACE command and a ACL request, that's a serious problem. Null resources help avoid that. It's not that somebody got their MKWORKSPACE request in ahead of mine --that's not the purpose of null resources at all. lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, June 05, 2001 1:03 PM > To: DeltaV > Subject: RE: Deleting versions > > > The only use case this addresses is that your client has > issued a MKWORKSPACE/LOCK sequence, and that in the narrow > time interval between the completion of the MKWORKSPACE > request and the LOCK request, some other client has managed > to discover the name of your new workspace and has issued > a LOCK request that somehow gets in before yours. > > I believe that not only is the likelihood of this happening > vanishingly small, but even if it does happen, your client > would just use the "that workspace is already in use > by someone else" response that it needs in case > somebody got their MKWORKSPACE request in ahead of yours. > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, June 05, 2001 12:08 PM > To: Clemm, Geoff > Cc: DeltaV > Subject: RE: Deleting versions > > > > > > What is the (compelling :-) use case for creating a lock-null > > resource before issuing the MKWORKSPACE request? > > > > What other way would you create a workspace and guarantee that it can't be > altered by other people before you set permissions and such correctly? > > Same goes for ACTIVITY. > > lisa
Received on Tuesday, 5 June 2001 17:03:18 UTC