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

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Fri, 24 Sep 1999 12:41:08 -0700

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:[email-masked]]
> Sent: Fri, September 24, 1999 2:48 AM
> To: [email-masked]
> Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios
> 
> 
> 
>    From: "Yaron Goland (Exchange)" <[email-masked]>
> 
>    <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
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 24 Sep 1999 17:44:50 -0400

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.

That is definitely a major loss ... would a write-in campaign to BG get
him to lighten your load?  (Probably not ... :-).

   I will

The proposed protocol would allow a server to lock the namespace,
but would not *require* it to do so.  This lets a low-end server
just lock the namespace, while letting a high-end server support
versioning and multiple bindings while ensuring a low-end (or any)
client access to his/her locked resource.  A win/win, I believe.

It's not the appearance of the history resource that is the issue.
It is the DELETE being applied by a down level client to a revision
that is supposed to remain part of the history of that resource.
The down level client is not aware of versioning ... it just wants
that resource to no longer appear at that URL.
If a DELETE is a DESTROY, that naive DELETE from a down level client
is required to blast that supposedly immutable persistent revision
out of existence ... a very bad thing.

Think Unix hard links (or for that matter, any implementation of
a reference in any programming language you can think of).  It's
easy to implement a delete of the reference, probably easier
(and certainly *safer*) than destroying the object.

In a file system, if you move a resource, it keeps its permissions.
I don't consider a file system something provided by only a super high
end provider, but they have no trouble moving permission style information
along with a resource (I know permissions are not locks, but analogous
implementations can be used).

See above.  It's true that I want versioning, but I also want things to
work smoothly and simply for legacy HTTP-1.x clients, locking clients,
and simple versioning clients.  Any argument that is based on "cannot
easily implement on a low end server or client" is one I care about
intensely.

I'll need to see something specific in the proposed protocol that
has the characteristics that you describe.  I know you don't have
time personally to bring this up, but I can promise that if anyone
does, that I care deeply that the protocol allow a simple implementation,
and will take all such issues very seriously.

Well, that's what I believe all of us have been trying to do for the
last few months (I *know* that I have), and the current proposal is
intended to be exactly that.  Keep interoperability with existing clients
and servers, while modifying the protocol to simplify it and to make
it support the extensions that were not fleshed out when the current draft
was written.

I need at least one example of such an unimplementable
feature of the protocol before I can address the issue.

Cheers,
Geoff