Reason for disappearing lock-null resources

I may be smokin' something, or maybe I'm just smokin' -- but I think I
reconstructed why lock-null resources were designed to disappear when their
locks go away.  It's because lock-null resources may be created
accidentally, then they may not be removable if the user doesn't have delete
permission.

Say I'm trying to lock Ch1.doc, but Jim renames it to Intro.doc.  If I have
write permission in the directory, my innocent lock request will create a
Lock Null Resource.  Now I try to clean up my mistake -- but Jim hasn't
granted me delete permissions on the collections so I can't.

Now, since there's a way of saying "LOCK this thingy only if it still exists
by the time you get around to processing my request", this motivation may
not be a trump.  Such a mechanism does exist: use the If header with some
handy existence-proving token -- like an ETag!  However, clients haven't
been told to do this and I betcha very few do.  If we think this motivation
is important, it may be safer to either keep the magic disappearing
lock-null resource behaviour, or make the recommendation to send If header
with LOCK whenever locking an existing resource.

(I still can't rationalize why you have to be able to turn a lock-null
resource into a collection though)

Lisa

Received on Sunday, 29 July 2001 23:31:49 UTC