RE: Locking

From: Tim Ellison/OTT/OTI (Tim_Ellison@oti.com)
Date: Fri, May 19 2000

  • Next message: Tim Ellison/OTT/OTI: "RE: Working resources in basic versioning"

    To: ietf-dav-versioning@w3.org
    Message-ID: <OF419A4E26.982239CB-ON852568E4.00456122@ott.oti.com>
    From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
    Date: Fri, 19 May 2000 08:45:57 -0400
    Subject: RE: Locking
    
       From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
    
       Section 2.3 has interesting sumer semantics when read literally.  It
    states
       explicitly that locks only apply to URLs with the same target selector
       value.
    
    <geoff/>Yes, that was how I intended it to read.
    
       This implies that the client cannot lock a labelled revision by
       it's URL and label target selector, and others can make modifications by
       specifying no target selector or an explicit revision ID etc. that
    selects
       the same resource.
    
    <geoff>
    I assume you meant "... that the client *can* lock a ..."
    
    <tim/> Yes.
    
    And if so, yes, that is the result I intended.  Do you disagree
    with those semantics, or do you just find them interesting
    (in a good way :-) ?
    </geoff>
    
    That is not the semantics that I would expect.
    Useful locking would protect the path that I took to the resource (so that
    others cannot move it out from underneath ne) and protect the resource
    bound at that path.
    If others can modify the resource via some other access mechanism (i.e. a
    different target selector) then the lock would appear not to be as useful,
    since it cannot be used to avoid lost updates.
    
    Tim