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

   From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

   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
   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.

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.

   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.

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.

   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.

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).

   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.

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 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.

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.

   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.

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.

   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.

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

Cheers,
Geoff

Received on Friday, 24 September 1999 17:44:51 UTC