Locking

In Xythos first generation server, locking a VCR locks the VHR and all
VERSIONS.

DeltaV defines these as completely different resources, and it has been
previously mentioned that they should be locked independently.

But it looks like things are more complex than they first appear.

A VHR is not appropriately a target of a PUT or a PROPPATCH on my
system.  What meaning could they have?  Note that we have been told that
in order to support global properties we should have people do a
PROPPATCH on the VHR.  

In my model of how that would work, the real resource being modified is
the VCR and all versions of the file -- not the VHR -- and a PROPFIND on
the VCR should see the global properties.  If the VCR is locked, a
PROPPATCH that modifies its state should fail.

It has been pointed out to me that this was probably not what the list
meant.  If such properties (set on the VHR) were not visible on the VCR
and you had to access the VHR to get them then someone implementing that
should allow a lock on the VHR.  However, in that case I wouldn't see
'setting VHR properties' as being a way to implement global properites.
I'd drop my plans to support PROPPATCH on the VHR, hence the reason to
lock the VHR.

Therefore, I see no reason why a VHR should be locked independently of a
VCR.  Either the operation is moot, or (in the case of guidance we have
received on global properties) the proper lock is on the VCR not the
VHR.

Next, we have past versions.  Past versions are not mutable (there goes
PUT and PROPPATCH).  A non-forking server such as mine does not allow
past versions to be checked out.  LABEL isn't supported, but is LABEL
supposed to honor a write lock?  I'm not so sure.  So I see no reason to
support a LOCK on a past version.

A CHECKOUT creates a 'state that can be modified'.  

In the case of Checkout-In-Place, that is logically the VCR.  I'm told
that there shouldn't be a real version in this case that can be accessed
independently of the VCR.  Again, only a VCR lock makes sense.

Yes, I note that I must provide for a lock on a working resource.

I'm just trying to find a reason whey I should allow it anywhere else.
I'm not seeing one.

Received on Wednesday, 12 September 2001 15:06:24 UTC