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

Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is
no longer the focus of my existence and my other duties are pressing so it
is difficult for me to properly contribute to these conversations. I will
throw in a few points of general experience that I hope will help:

1) I guarantee that if you change the way LOCK works you will end up with a
protocol that will be unimplementable on the majority of existing systems.
The namespace is locked by a LOCK request for a damn good reason, if you
change it, most of us implementers will probably just be forced to ignore
you so we can properly support our users.

2) A link to the history resource should never appear to a down level
client, they should only see a URL to a tip version. If this is not the case
with the version design then the version design is broken.

3) MOVE doesn't move locks due to interoperability issues. If you want a
protocol no one but a couple of super high end providers can ship then go
right ahead, make the change.

The problem here is that the people really working hard on this protocol,
folks like Geoffrey and JimA, are basically super high end people. They are
not used to having to live in the crappy, confined, miserable, limited hell
known as consumer software. Therefore they make proposals which are 100%
consistent, elegant and imminently reasonable, if you are shipping a super
high end system.

I don't see any voices actively participating in the mailing list who speak
for the dirty masses yearning to be free. I also see absolutely no voices
speaking for people who actually write clients for a living. 

Asad and I used to represent the dirty masses and I did a good pitch at
representing clients (having worked on IE for all those years) but no one
seems to have taken our place. The discussions here are very far removed
from the reality of consumer software. You are creating a standard that will
only be implementable on brand new, high end systems. Existing users will
simply be screwed. WebDAV's current success has been that 2518 is easy to
implement. The stuff you guys are creating and the changes you are proposing
to 2518 to allow you to implement your super high end features will kill the
lower end market.

As a last note, SHOW SOME ORIGINALITY! I mean, come on! You guys are so....
wooden. "Gee I got a DELETE on the history which doesn't have the magic
'foobar' header. I guess I better just delete the link." Come on! Protocols
are fun. Stop being so limited in your thinking. "Must change whole protocol
to fix down level problem." Like hell. We put in versioning and ignore rules
for a bloody reason! Come on folks, a little out of the box thinking,
please.

Either way, you better find someone who works on clients and consumer
software who actually has time to devote to WebDAV and fast or you will fail
to produce a protocol that will be widely implementable. I assure you, you
are already far along the path of unimplementability as it is.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Fri, September 24, 1999 2:48 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios
> 
> 
> 
>    From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
> 
>    <yg/> 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. ...
> 
> <gmc/> I agree with Yaron that we do not want to bite off general
> transactioning support as part of WebDAV.
> 
>    <yg/> 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.
> 
> <gmc/> If lock were *really* just associated with the 
> resource, I'd be a
> happy camper.  For one thing, it would mean that when multiple URL's
> are mapped to a single resource, you could issue the LOCK against any
> of those URL's and the result would be identical.  Similarly, 
> you could
> later on issue on UNLOCK against any of those URL's and 
> again, the result
> would be identical.
> 
> <gmc/> But I have seen various arguments in the past that a 
> LOCK should
> also protect the URL to resource mapping.  If "protect" just means
> "keep from being deleted", then your conclusion still holds, i.e.
> it makes no sense to LOCK a deleted resource.  But if protect also
> means "reserves the right to change the URL to resource mapping",
> then it is perfectly sensible to keep a LOCK after the resource is
> deleted (that is pretty much what a lock-null resource is anyway).
> 
> <gmc/> I personally believe that the best answer is to fix the LOCK
> semantics so it *really* is just on the resource (and not on the
> name).  Then things are simpler and consistent, even in the case of
> multiple URL mappings to a resource.  Rather than "protecting" a URL
> to resource mapping, I'd propose that a locked resource be allowed to
> MOVE (this is just a change to the state of the parent collection, not
> to the state of the resource being moved), but that an attempt to
> access the MOVE'd resource with that lock just returns a 302 
> indicating
> where it has MOVE'd to.
> 
> <gmc/> And as for the question of whether DELETE deletes all bindings
> to a resource or whether it just DELETE's the binding named in the
> DELETE request-URL, I am an adamant supporter of the current advanced
> collection protocol specification which states that it *only*
> deletes the binding named in the DELETE request-URL.  This behavior
> is *essential* in order to allow versioning-unaware clients to
> be able to issue a DELETE without destroying the history of a
> resource.
> 
> <gmc/> So there are really multiple threads here:
> - Should locking be on a resource or also/instead on a URL-to-resource
>   mapping?  (we know what it is now, but what *should* it be)
> * I vote "on a resource".
> - Does a DELETE delete all bindings to a resource, or just the one
> specified in the request-URL.
> * I vote "just the one named by the request-URL".
> - Should a DELETE delete a LOCK?
> * I vote, "no".  A DELETE modifies the state of the 
> collection containing
>   the binding, not that of the resource.  In particular, all other
>   mappings to that resource will continue to exist and display the
>   LOCK'ed semantics.  If you want to prevent a DELETE, you put the
>   LOCK on the collection whose state is being modified.
> 
> <gmc/> I realize that this requires changes to 2518, and I would not
> make such a suggestion lightly.  The problem is that 2518 was 
> specified
> without the use cases of multiple bindings and versioning in mind,
> and needs to be revisited now that those use cases have been 
> elaborated.
> 
> Cheers,
> Geoff
>

Received on Friday, 24 September 1999 15:41:13 UTC