Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

Here is a proposal I think someone else posted a while back.

- LOCK on existing resource stays as is

- LOCK on unmapped URI should (must? can?) create a non-collection resource

- UNLOCK on the same URI without a PUT should (can?) delete the resource

- 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.

(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).

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.

The problem with this however was a sequence of LOCK /a, MKCOL /a
would probably have troubles (MKCOL would not like the fact that
/a already existed). The implementation would have to remember that
the collection created was temporary (which is probably fine actually)
so the MKCOL just clears the 'temporary' status of it.

Another variation (which could always be added later) is to add new
variations of LOCK which has an additional mode/flag/header field to
'create collection resource' and 'create non-collection resource' so
you can create and lock in an atomic operation.


One question then. If LOCK on an unmapped URI creates a resource,
should the resource be marked with a WebDAV property of being 'temporary'.
That way a PUT or MKCOL on an existing resource marked as 'temporary'
could behave as if the resource did not exist before (and return 201).
The implementation however would simply clear the 'temporary' flag.
A PROPFIND on the resource would also clearly identify it as being
temporary.


There are lots of variations possible. One could even go full circle
and say "well, temporary resources are really just LNR's". The only
difference is that LOCK on a unmapped URL should be able to determine
in advance if its going to be a non-collection or collection resource.
That way an implementation can send things down to the lower level
file system if needed. (ie, it can create a temporary file or directory
which other applications see as a file or directory - not as a LNR).

Also in the new proposal, an UNLOCK does not have to remove the LNR
(it should, but its not mandatory). To be clean, I would say it really
should be a MUST not a SHOULD, but some existing implementations don't
do it correctly. I guess backwards compatibility with currently
implementaions is not a requirement.

Oh dear, I seem to be arguing against myself. In this last bit I guess
I am really saying maybe the problem with LNR's is that they dont have
a resource type (collection/non-collection) when they are created.
If they did have a resource type, then they could be immediately
created as such a resource in the underlying file system. The WebDAV
layer could remember that they are 'temporary' (LNR) resources and
so remove them later, or make PUT on them return 201 etc.

Alan

Received on Thursday, 2 August 2001 02:30:11 UTC