Re: What is left after LOCK/UNLOCK on null resource?

Michael,

Just for the record, I disagree with most all of Geoff's responses here 
(and in the subsequent thread), and I don't think he speaks "for the 
working group" in saying that the DAV spec favors time-limited locking.

In the first place, I think client implementation (at the level, for 
example, of "process") is way outside the scope of the spec.

Second, I believe that the language of the spec (as written) 
intentionally doesn't say much at all about what constitutes an 
"authoring client" (see section 6 on locking).  I think that's 
appropriate both because HTTP 1.1 is profoundly neutral about it and 
because WebDAV hopes to allow a broad range of interoperable 
implementations.

Third, there is a broad class of existing, interoperable 
implementations (the Adobe Systems WebDAV-enabled products) which 
communicate tokens among processes, persist tokens between invocations 
of processes, and use LOCKDISCOVERY values (both tokens and owner 
props) as a means of interoperating on the client side about authoring 
responsibility.  These impementations work against servers which allow 
infinite-duration locks and those which don't.

FWIW, I believe that lock expiration is really tied to a usage model in 
which clients actually use the server as a "remote file system," in the 
sense that they may only have a non-persistent buffer locally and all 
saves are done directly back to the server.  This is the model that 
Microsoft office clients use, for example, and they use lock timeouts 
as a way of preventing lock stranding when clients crash.

The model you outlined---a local working copy is made of a locked 
resource, that local copy is edited over an indefinite period of time, 
that local copy is occasionally "published" to the server, and then the 
server resource is unlocked after all local editing is complete---is 
exactly the model used by Adobe clients.  (I have been meaning for some 
time to write an explanation of why Adobe uses this model; maybe this 
thread will finally get me to do that.  Then again, maybe not. :^)  
But, in any event, it is quite natural in this model for lock tokens to 
be persisted by the editing clients that are using the local copy, 
because in this model all the editing state (including the lock token 
and owner information) is local-disk-specific not process-specific.

Finally, I'm not really sure why Geoff says that delta-V is 
specifically better suited than "plain" DAV for use by clients who use 
long-term locks.  Versioning servers are arguably a better choice than 
non-versioning servers for almost all collaborative authoring 
applications, delta-V is (of course) a DAV extension, and in fact 
delta-V specifically provides for backward compatibility around DAV 
locking for non-delta-V clients who wish to get the benefits of 
versioning.  So I really don't think lock (or checkout) duration has 
much to do with the difference between delta-V and DAV.

     dan

On Wednesday, September 4, 2002, at 07:28 PM, Clemm, Geoff wrote:

>
>    From: Michael Leditschke [mailto:mike@ammd.com.au]
>
>    DAV locks are
>    supposed to be capable of being held for an extended time.
>
> Only by the process that took out the lock.
>
>    I might
>    want to lock a resource, edit it for a while locally, then push the
>    result back and unlock it again. Are you suggesting this all has
>    to be done by the same OS process?
>
> Yes.
>
>    What happens if the power goes out and my PC reboots?
>
> The new process needs to obtain its own (new) lock.  The old
> lock is cleaned up by a timeout, or if allowed by the server,
> the new process can clean up the old lock with an UNLOCK.
> The new process shouldn't "reuse" the old lock, unless you have
> some way of guaranteeing that two processes cannot both reuse the
> old lock at the same time.
>
>    Or perhaps you expect the client to cache locktokens?
>
> Only if the cache has some way of guaranteeing that only one
> process can obtain the cached locktoken.
>
>    In my case, it is the same client I'm using to lock and unlock and
>    I'm presenting the same credentials to the server. Its a low
>    level test program, so I would have thought being able to unlock
>    a resource of which I am the owner would be reasonable.
>
> Unlocking is reasonable (unlike "reusing", which is not), but some
> servers do not trust clients to appropriately unlock something they
> didn't lock (since the client can't automatically know that it is
> appropriate to do so, and even if it asks the user, the user can be
> mistaken).  Those servers require clients to depend on timeouts.
>
> Cheers,
> Geoff
>

Received on Thursday, 5 September 2002 12:22:24 UTC