Re: resourcetype locknull

   From: ccjason@us.ibm.com

   Or similarly LOCK, DELETE (leave null lock flag), PUT, PROPATCH, UNLOCK....
   ala MKRESOURCE.

   Or LOCK, DELETE (null lock left), COPY (tree perhaps), play, UNLOCK.

   Or xserver COPY...   LOCK (depth), DELETE, PUT, MKCOL, PROPATCH, MKCOL, etc
   UNLOCK.
   And reduces possible error conditions in the middle of sequences of methods that
   a client might want to invoke.   And facilitates backing things out if it has an
   error... because it knows what the state is and can feel safer about backing it
   out...  (depth null lock)

As Jim Amsden mentioned, 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.

   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.

If you look at it from the server side, removing lock null resources
is of course an unconditional win (Jim Amsden already made that point
in an earlier message).

Cheers,
Geoff

Received on Thursday, 14 October 1999 10:17:13 UTC