RE: resourcetype locknull

> "Geoffrey M. Clemm" wrote:
>
> > Isn't this functionally equivalent to someone getting the lock on the
> > lock null resource between the time when you issued the lock request
> > and the time it was handled by the server?  The fact that they got the
> > lock on the empty dummy resource you created, as opposed to a lock on a
> > "lock null" resource doesn't seem to change the situation in any
> > substantive way.
>
> 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.

This is a pretty good restatement of the original rationale for lock-null
resources.

Given the preponderance of evidence that indicates this is a difficult
feature to implement, and since the arguments claiming that the feature is
not strictly necessary appear to be sound, I would be happy to remove this
feature as we move from Proposed to Draft standard, assuming that doing so
does not create any interoperability problems.

Yaron's currently on vacation, he may wish to defend this feature when he
returns. I'm certainly not going to, unless I hear a compelling counter
argument.

- Jim

Received on Thursday, 14 October 1999 20:42:45 UTC