Subject: Re: resourcetype locknull

From: [email-masked]
Date: Thu, 14 Oct 1999 13:11:06 -0400

Geoff,
That's exactly how I feel about it too. With MKRESOURCE, perhaps even PUT
shouldn't create resources as a side effect, but we have to be compatible with
HTTP conventions.

"Geoffrey M. Clemm" <[email-masked]> on 10/14/99 10:23:30 AM

To:   [email-masked]
cc:

Subject:  Re: resourcetype locknull

   From: [email-masked]

   <jra>
   We could eliminate lock-null resources, and keep the ability to reserve a
name
   in the namespace if LOCK on a null resource created a resource with an empty
   body and locked it. Since LOCK on a null resource isn't going to respond with
   404 Not Found anyway, it might as well create the resource.
   </jra>

Having LOCK create a null resource as a side effect?
This can't be "no control coupling" Jim Amsden talking here! (:-).

But seriously, I could easily live with this proposal.  Although I am
aesthetically against control coupling of this kind (i.e. creating a
resource and locking a resource should be two separate and orthogonal
requests), I could live with it if that's what it takes to get rid
of lock null resources.

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 14 Oct 1999 13:23:46 -0400

That's good to hear ... that means the body-snatchers didn't
get you after all (:-).  I'm actually not as concerned about
PUT and MKRESOURCE being allowed to both create and update
resources, since they both know what kind of resource should
be there when they are done.  I think LOCK is very different
because you *can't* infer from the LOCK call what kind of resource
should be created if none is there at the moment.

Cheers,
Geoff

   From: [email-masked]

   Geoff,
   That's exactly how I feel about it too. With MKRESOURCE,
   perhaps even PUT shouldn't create resources as a side effect, but we
   have to be compatible with HTTP conventions.