Re: resourcetype locknull

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

This proposal essentially creates a resource and that resource
has special properties... no guid?  special resourcetype?  MKCOL?.  I
guess that could be fine... but it also sounds like it's largely
the same as our current lock null resource.  At least in implementation
and behavior... even if different in conceptual model.

<brainstorm>The thing is, the
goal of this isn't really to create a resource... it's to reserve the
the namespace and perhaps to provide for some atomicity subsequently.
The ideal would be a lock that is rooted in the slot of the parent
collection where the binding resides.  This doesn't fit our current
data model since we never really talk about slots.  This does resolve
a few problems though.  (No, I'm not making a proposal at this point.
Just brainstorming.)
</brainstorm>

Received on Thursday, 14 October 1999 11:40:50 UTC