- From: <ccjason@us.ibm.com>
- Date: Thu, 14 Oct 1999 00:29:26 -0400
- To: John Stracke <francis@ecal.com>
- cc: w3c-dist-auth@w3.org
Consider what happens if you need to create a resource with a particular body and some particular properties. If you don't have lock-nulls (or transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK (or maybe skip the LOCK/UNLOCK, since it's only protecting one operation). If you and somebody else are trying to create it at the same time, then you could get PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties don't match its body. With lock-null, you can do LOCK, PUT, PROPPATCH, UNLOCK. 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) 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.
Received on Thursday, 14 October 1999 00:25:23 UTC