Re: DELETE leaving a lock-null resource; was LOCK Scenarios

<gmc/> After slightly wavering, I'm firmly back in the:
"just say no to lock-null resources" camp.
We just don't need the complexity of a "non-resource resource"
for the minimal gain it provides.
Cheers,
Geoff
 From: jamsden@us.ibm.com
 <jra>
 There are a large number of situations in authoring environments where
 transaction semantics are required. WebDAV doesn't (yet) support transactions,
 and I don't think we should attempt to come up with a lot of special cases (like
 lock-null resources) supported by the protocol to overcome this important
 missing function. Rather let's propose an extension that does support
 transactions. Might be pretty hard with a stateless server though.
 </jra>
 <JC>
 So you're not a fan of lock-null resources either at this stage. That seems
 consistent.
 JimA and I have been doing all the talking for the last day. Anyone else want
 to be heard? :-)
 </JC>
 <jra>
 I don't really care that much one way or the other about lock-null resources. I
 think they add a lot of complexity to the protocol for little functional gain
 and wouldn't be opposed to removing them. But if they stay, that's OK too. If
 lock-null stays, then I think it would be reasonable for delete on a locked
 resource to change the state of the resource to a lock-null resource. To
 complete the delete, the client would have to do the unlock. This is at least
 consistent semantics and allows the protocol to support symmetric resource
 life-times.
 </jra>

Received on Thursday, 23 September 1999 11:21:53 UTC

AltStyle によって変換されたページ (->オリジナル) /