Re: Creating a lock-null in a locked collection

Jim,
WebDAV locking semantics are defined independently of the actual server
implementation. If a server provides multiple protocol access to some
underlying storage system, including WebDAV and say ftp, then that server
is free to implement locks in such a way that both protocols are effected
as long as the semantics for WebDAV locks are honored when doing WebDAV
access.





Jim Davis <jrd3@alum.mit.edu>@w3.org on 01/02/2000 03:54:46 AM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: Creating a lock-null in a locked collection


At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote:
>
>As an addendum to Yaron's response, I'll note that there is a proposal
>that WebDAV locking is better understood as locks on URL's rather than
>on resources.

I am not sure I understand what "is better understood as" means here.

I would like it to be the case that if I have a datastore (file system, an
object oriented database, an RDBMS, whatever) that *does* support locking,
I can use the WebDAV to set a lock on a resource in the datastore,  and
expect the lock to actually be set on the resource such that other
applications accessing that very same resource likewise see the lock, even
if they use a different protocol or API to do so.

I may be reading more into the nuances of language than is intended, but
does this mean that WebDAV locks would only be visible at the WebDAV layer
(or perhaps to other protocols that also use URLs) but *not* to other
protocols or APIs that were accessing the same resource?

I would be very unhappy with a design change that asserted that the locks
were only in some "namespace" that only affected WebDAV, or HTTP-based
applications, but not the datastore itself.

I would probably prefer to give up the functionality of BIND than lose the
ability to set locks on underlying resources.

But again, I am not sure that Geoff was actually suggesting this.

regards and happy Y2K

Jim

Received on Monday, 3 January 2000 11:09:52 UTC