versioning lock null resources

Lisa says:

>>A direct read of this paragraph combined with deltaV draft 15 (and your
implication) would indicate that you can't issue a VERSION-CONTROL method 
on
a lock-null resource.  That's bogus.  A "write locked null resource" is
there so that the creator can do all the write operations and state 
changes
they need before making the resource visible to everybody.

So, I suggest that VERSION-CONTROL (and perhaps other methods like 
CHECKOUT,
MKWORKSPACE...) should be explicitly allowed by DeltaV to be done on write
locked null resources, and that the spec define a precondition that can be
returned if the server decides not to allow operations on write-lock
resources.<<

The purpose of lock null resources was to provide an atomic operation for 
creating and locking a new resource. It was not to control visibility of a 
resource until the creator is ready to "release" it to the community. Lock 
null resources do appear in PROPFIND of collections with dept 1 or 
infinity, and do respond to PROPFIND themselves. This is a hack solving a 
specific instance of a problem without coming up with a general solution 
(which would probably require Web transactions). What problem would be 
solved by allowing versioning of lock null resources? What would it mean? 
What would be the contents of the root revision? These are all questions 
that will be difficult and arbitrary to answer resulting in the current 
approach to handling lock null resources.

Received on Tuesday, 19 June 2001 07:31:49 UTC