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

The suggestion has been made that we introduce transactioning. I hope you
will not think me cheeky if I summarily reject the suggestion of using
transactioning. I, for one, would really like to be able to sell webdav
servers for something under $100,000 a piece.

Small problems need small solutions.
Big problems need big solutions.

Lock-null solves a small problem. We do not in the 99% case need
transactioning. There are systems that need transactioning and for those
guys I would recommend looking at TIP (RFC 2371). I actually released a spec
at one point specifying how to use TIP with HTTP and I have another spec I
haven't released which shows how to implement the TIP protocol itself using
HTTP. I did the later mostly because I hate seeing people inventing
arbitrary new protocols which can be implemented with existing systems for
no particularly good reason. But I digress...

Either way, lock null, much like PROPPATCH and LOCKs themselves, were
introduced to cover small areas of transactioning like semantics that even
low end systems require. Believe me, we WANTED to require transactioning.
Every time I look at PROPPATCH I want to vomit. It violates just about every
principal of good protocol design. I have similar feelings about
multi-status but that was required due to a flaw in HTTP's design not due to
the lock of transactioning. In either case, we had to make a choice between
designing a system that people could implement and one that read well on
paper.

BTW, in so far as what happens when you DELETE a locked resource I
completely oppose the suggestion that DELETING a resource results in a
lock-null resource. That is absolutely contrary to the definition of DELETE.
DELETE deletes the resource not the name. Since the lock is associated with
the resources deleting a locked resource deletes both the resource and the
lock.

		Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, September 23, 1999 8:22 AM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: 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 Friday, 24 September 1999 02:40:27 UTC