- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 2 Aug 2001 10:18:22 +0200
- To: "Alan Kent" <ajk@mds.rmit.edu.au>, <w3c-dist-auth@w3.org>
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Alan Kent > > Here is a proposal I think someone else posted a while back. Very close: > - LOCK on existing resource stays as is > > - LOCK on unmapped URI should (must? can?) create a > non-collection resource MUST if the namespace is kept consistent. > - UNLOCK on the same URI without a PUT should (can?) delete the resource Same holds true for LOCK timeout. should or can is the question. > - MKCOL on a LOCKed unmapped URI will fail (pity, but too bad). > > This allows implementations to create a file in the underlying file > system if they want to. > > In order to completely remove the concept of LNR, PROPFIND must be > cleaned up too. Here are some alternatives: > > (1) I would say a LOCK on a unmapped URI MUST create a resource > and lock it. > That way it will appear in PROPFIND's. A PUT on the resource > would then > say 200, not 201. That's what I would expect. > (2) If a LOCK creates a temporary file, PROPFIND returns it. If a > LOCK does > not create a temporary file, PROPFIND does not return it. > > (3) Keep more of the current semantics. PROPFIND returns info about LNR > resources. If your implementation creates a temporary file, then your > implementation does not have to worry about LNR (but it stays in > the standard as a concept). That makes life of clients unnecessary difficult. > I was actually going to propose a new optional flag to say for locks > that the intent is to create a non-collection resource or a collection > resource (where non-collection is the default for backwards > compatibility). The idea is in order to be able to create a temporary > placeholder resource in the underlying file system, get the client to > say in advance whether it is going to PUT or MKCOL. Have a default > value of PUT means MS Word will probably be conformant as is (or pretty > close) for example. > > [removed neuronal interference patterns] The question is what to do with such resources when they are unlocked or the lock times out. Possibilities: 1. If the resource disappears, WebDAV still has the concepts of LNRs and servers have to track resources created by a LOCK. 2. If the resource stays as an empty file, the concept of LNRs can be removed completely from the spec. Additionally, servers would have no need to track resources created by LOCK. I favour the second approach. It gives most bang for less bugs. //Stefan
Received on Thursday, 2 August 2001 04:19:01 UTC