Re: Locking URIs rather than Resources

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