Re: resourcetype locknull

   From: ccjason@us.ibm.com

     ... according to 2518 you will lose your LOCK as soon
     as you issue a DELETE, so you will have to request another LOCK, and there
     will be a window of opportunity for someone to get in ahead of you with
     their LOCK.  But their doing so does not introduce any lost update issues,
     but just says that you have to wait for them to finish instead of the other
     way round.  This is just the normal situation in distributed authoring.

   Right.  That's what 2518 says.  That's why I explicitly noted it.  But
   we haven't completed the spec.  The assumption is that we'd support this.  If
   we do... we could use lock null resources in this way.  See my previous
   postings on this.

Fair enough.  I was criticizing lock null resources as they are defined
in 2518.  Any attempt I have seen to improve the semantics of lock null
resources ends up fixing some problems at the cost of even greater complexity.
So I'm not saying that they don't solve any interesting problems (they do),
but rather that the cost of providing them outweighs the benefits they
provide.

      Question... what situations are complicated by lock null resources.  I'm sure
   we
      must have covered this, but I forget what they were and I didn't record them.
      I'd like to record this in the issues list.

     With lock null resources, a client has to think about
     what special thing they might need to do in case what appears to be
     no resource in some cases (404 coming back from a GET), appears to
     be a resource in other cases (PROPFIND).  In particular, the client
     needs to indicate this fact somehow to a user when the user requests
     information about a collection.  So it is not just the client but
     the user that pays a cost for this feature.

   Interesting.  I'll note that... and give it more thought.  JimA just posted
   a proposal that would resolve this.  Something about giving the null resource
   a body.  To some extent... it no longer would be a null resource then though.

Albert's point (in my opinion) squelched that proposal (:-).  Unless
you allow MKRESOURCE to "mutate" a resource to a new resource type,
you will have to delete the resource created by LOCK in order to get
the right resource type, and if we hold to the model that LOCK's are
on resources (not URL's), then when that old resource is deleted, it's
lock cannot be inherited by some new resource at that same URL.

Now I suppose we *could* just say that you can use MKRESOURCE to
"mutate" a resource of one type into a resource of another type,
but that's probably a cure that is worse than the disease ... (:-).

Cheers,
Geoff

Received on Thursday, 14 October 1999 13:13:09 UTC