Subject: Re: resourcetype locknull

From: [email-masked]
Date: Thu, 14 Oct 1999 11:44:42 -0400

Whoops, I thought I already sent this...

   From: [email-masked]

   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.

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.

Right, deleting the lock doesn't create a lost update problem.  It does cause
a problem where someone else can slip in a lock, thus block you, abort
themselves
because what they expected there is no longer there.  But of course you've
already
done the delete, so you've only done a partial execution and you can't really
back out.  You've lost atomicity.   So to get around this a client app might do
a MOVE
instead of a delete... so at least it has a chance of backing out your change,
but once again someone else's lock can block it even if it's a temporary lock.
As you see... this type of atomicity is not achievable without the this type of
lock.

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

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

I'll look for that posting and list it here.

---

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

From: [email-masked]

     ... according to 2518 you will lose your LOCK as soon

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.

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

---

From: [email-masked] (WJCarpenter)
Date: Thu, 14 Oct 1999 11:21:00 -0700

gmc> So I'm not saying that they don't solve any interesting problems
gmc> (they do), but rather that the cost of providing them outweighs
gmc> the benefits they provide.

Back when this was invented, someone must've thought there were
scenarios where it was pretty important to be able to reserve
namespace to be used later.  Would someone care to lay out some
scenarios where this is pretty important?  (I'm not disputing it.
Just looking for an education.)
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3