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

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

Oh but I'm working on such cool stuff!!!! SSDP, GENA and HTTP over UDP just
rock the universe! What is really cool is how we are starting to integrate
DASL into GENA. In addition I will be exploring some other really cool areas
that I can't talk about but which will bring me right back to WebDAV. But
for the moment I have to focus my attentions elsewhere. I will try my best
to review specs when they reach "maturity" points. That is what I have been
trying to do with the advanced collection specs.

> 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 is lose/lose if you are a client writer. When I write my client I MUST
know EXACTLY what the behavior is. I can not have a situation where I am
editing a document in Word, I lock the document and then the damn name
changes! When I lock a resource I am also locking the name I am editing that
resource under. It MUST NOT ever change. Any other behavior makes writing a
simple client impossible.

One of the really scary things I have heard both you and JimA say is how
glad you are that WebDAV will offer many choices and allow for various
gradations of service. THIS IS A MISTAKE! We are in the standards business,
not the buffet business. Choice kills interoperability. That is what makes
standard writing so damn hard. You can't give everyone everything and have
interoperability so you have to screw over everybody. Hence the definition
of compromise as "When no one gets what they want."

I would remind everyone of two very important WebDAV maximums:

1) The spec is done when there is nothing left to cut.
2) There are two types of features, mandatory and not in the spec.

Just making locking optional required six months of debate and almost
resulted in bloodshed.

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

This is what I mean about thinking out of the box. Someone said "this
resource is versioned." Once you have an affirmative command like that you
can do anything you want. For example, you can say "A DELETE on a versioned
resource without the magic foobar header deletes all links but the one to
the history, not the resource." Now, before both you and JimA scream at me
in stereo "BUT YOU MORON! THAT IS WHAT WE HAVE BEEN SAYING!" let me tell you
what I heard you say:

JimA & Jeff: A DELETE will delete a binding not the resource.

Now let's compare that to what Yaron is saying.

Yaron: A DELETE on a versioned resource without the magic foobar header
deletes all bindings but the one to the history, not the resource.

Notice the difference. The default behavior for DELETE is still to nuke the
resource. But in a case where we have positive affirmation that the behavior
is to change then change away.

Also notice that this DOES NOT mean that DELETEing a resource with
references only deletes the reference. It only applies to the particular
case of a versioned resource.

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

True but it doesn't keep its locks. The file system has no way to maintain
the lock across moves. This becomes especially important for the average
case where you need to expose that lock through multiple protocols. These
are the sorts of nitty gritty issues you only live and breath if you ship
file systems for a living. The problem is that none of the active members
seem to do that.

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

How about locks surviving moves? How about allowing the name of a file to
change when locked? The first can't be done by most servers and the second
can't be handled by most clients.

		Yaron

Received on Friday, 24 September 1999 20:23:14 UTC