- From: Jim Davis <jrd3@alum.mit.edu>
- Date: Sun, 09 Jan 2000 09:08:13 +0100
- To: w3c-dist-auth@w3.org
At 03:44 PM 1/7/00 -0800, Eric Sedlar wrote: >Let's say that I have a "book" entity that I want to manifest as a collection >resource ...Let's say that this book is a programmer's guide for a software >product, and a couple of these chapters are about "Getting Started". Now ... I want to move those >chapters into a third collection containing shared resources between the >manuals. I have the following collections now: > >/manuals/prguide >/manuals/common >/manuals/admin > >When I started working on the programmer's guide (PG), I depth:infinity lock >the entire collection with a shared lock, to make sure nobody messes with the >chapters while I am working. This is a good use case, thanks for contributing it. I think it's reasonable to require that something like this work. But I don't agree that it shows a problem. I think there are at least three ways to use WebDAV and meet your requirements. 1) lock the common collection with depth infinity. Then when you move the files, they are added to the lock. 2) Create a temp collection, depth lock it, move the files there. edit them until you are ready to release the lock, then move them to the common collection, where they will be seen by your co-workers. 3) For each file that you wish to move to common, lock a null resource in the common collection. then do the moves. the formerly locked-null resources will become locked "normal" resources. Is at least one of these acceptable? Note that I am talking about WebDAV as in RFC 2518, I am not completely sure these apply to the newer proposals for lock. >Therefore, I think it is better that the client (i.e. the application) have >specific control of the locking semantics, and that the server not try to do a >lot of funny stuff with guessing what the client wants. That's a good principle in general.
Received on Sunday, 9 January 2000 03:53:51 UTC