- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 15 Jun 2001 15:46:02 +0100
- To: "'W3C WebDAV Mailing List'" <w3c-dist-auth@w3.org>
- cc: "Jim Whitehead" <ejw@cse.ucsc.edu>
Lock nulls don't deserve the effort of the debate <g>, but I know that Shaun is a reasonable person so as a courtesty to him... JimW: there's a couple of typos that need fixing too. "Hall, Shaun" <Shaun.Hall@gbr.xerox.com> wrote: > Let us remind ourselves about a few things here (in conjunction > with null resource emails): > > 1) Locking's purpose it to avoid conflict, the lost update problem > etc (RFC2518 sec 6). Agreed. > 2) A null resource MUST NOT appear as a member of its parent > collection (RFC2518 sec 3). That's interesting, because Section 7.4 (which I was reading) states that it MUST appear as a member of its parent collection.<g> By copy to JimW. Please add this to the RFC2518 issues list. I'd have thought that the correct answer was that it MUST appear as a member of its parent, otherwise the namespace is not reserved. > 3) A null resource MUST respond with a 404 for ALL methods > other than PUT, MKCOL, OPTIONS and LOCK (RFC 2518 sec 3). And UNLOCK. Geeze, there's another for the list Jim<g>. Good job you read section 3 Shaun. > 4) Lock null resources (LNRs) are there to reserve name (RFC2518 > sec 7.4). They are there so a client can reserve the name *before > they create the resource* (store the "entity"). Admittedly, a > server may use a file to represent the LNR, but thats an > implementation detail. Since the name is reserved, it avoids > potential conflict when the entity is actually stored e.g. with > a PUT. I couldn't find the bit about "before they create the resource". The use of a file is a red herring, I have never suggested that any DAV server has to use files at all, in fact the opposite, I've always objected to such statements. If a lock null resource is not a resource, then what is it? > 5) Methods performed on LNRs other than PUT, MKCOL, OPTIONS, > PROPFIND, LOCK and UNLOCK MUST respond with a 404 or 405 (RFC > 2518 sec 7.4). Agreed. The lock-null resource is dictated to respond to methods in a certain way -- but so are other resource types that are defined in DeltaV versioning for example. > 6) If you UNLOCK an LNR, the resource is returned to the null > resource state (RFC 2518 sec 7.4). This may mean a server > actually deletes the "file" it used to represent the LNR, but > thats another implementation detail. Agreed. The implementation is irrelevant here. > The client should assume nothing about how the server implements > the protocol, in these cases, null resources and LNRs. Agreed again, it could all be in memory, in a RDBMS, whatever, I don't care. However, when a lock-null resource is created, there is a resource and it has a URI. The "null resource state" is also a term introduced by RFC2518 and not properly defined. > A few people interpret 2) and 3) to mean that a null resource > doesn't physically exist, which IMHO is convenient. As far as > the client is concerned, a null resource doesn't exist as per > 3), and an LNR doesn't exist as per 5). We can have a very interesting discussion about lock-null resources and null resources ... I happen to believe that the ideas are bogus but the problem to solve (your point (1) above) is real. Tim
Received on Friday, 15 June 2001 10:50:21 UTC