RE: Locking

   From: John Hall [mailto:johnhall@xythos.com]

   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.

Yes, it is fine for your client to present a model to the user that a
lock on a VCR also locks the VHR, but to be compatible with the
protocol, that should be marshalled as two LOCK requests, one to the
VCR and another to the VHR.

   A VHR is not appropriately a target of a PUT or a PROPPATCH on my
   system.  What meaning could they have?

A PUT is undefined on a VHR (just as PUT is undefined on a collection
and an activity).  PROPPATCH is meaningful ... it gives the VHR a
property (DAV:displayname, or some custom property).

   Note that we have been told that
   in order to support global properties we should have people do a
   PROPPATCH on the VHR.  

The way this would work is that your GUI would display both the
properties of a VCR as well as the properties of the VHR, thus
effectively displaying the VCR as "inheriting" the properties of its
VHR.  You would have to make some decision about what to do in the
case of conflicts (i.e. when both the VCR and VHR have the same
property with different values).  A client would be responsible for
deciding whether a the property is a "global" (on the VHR) or "local"
(on the VCR) property (assumedly based on some GUI gesture from the
user).

   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.

Your client can present any model that it wants, but to interoperate
with multiple servers, it needs to adhere to the DeltaV semantics,
in which the VCR and VHR are separate resources with their own locks.
Similarly, your client can do whatever it wants in terms of displaying
a global property model, but to provide an interoperable form, it
must use DeltaV/WebDAV compatible requests (such as modeling global
properties as properties of the shared VHR).

   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.

I agree that being able to lock a VHR is of neglibible value.
Someone might decide to implement global properties by placing
them on the VHR, in which case being able to lock a VHR would
be of value to that client, but not a very compelling use case
for me.

   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.

See section 1.8, Versioning Methods and Write Locks:
 If a write-locked resource has a non-computed property defined by this
 document, the property value MUST NOT be changed by a request unless
 the appropriate lock token is included in the request.  Since every
 method introduced in this document other than REPORT modifies at least
 one property defined by this document, every versioning method other
 than REPORT is affected by a write lock

So yes, labels are controlled by write locks, but since the LABEL
method gives you incremental add/delete capability, there is little
or no reason to "lock" the version for a LABEL request.

   So I see no reason to support a LOCK on a past version.

I agree.  Locking a version is even less likely/important than locking a
VHR.

   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.

I agree.  Locking a VCR is the prime locking use case.

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

Yes, although since a working resource has an obscure URL, it is
unlikely that anyone will try to use your working resource, so
locking is probably not all that important for working resources.

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

If you only handle locking of a VCR, I believe you will handle 98%
of the important use cases.

Cheers,
Geoff

Received on Wednesday, 12 September 2001 16:43:31 UTC