RE: Status code for creating lock-null resource

> I agree with all of this. (Despite Section 3 of RFC2518 that
> states clearly that a null resource is a resource.)

When that was written, I had a different model in my head.  In that model, a
null resource was in fact a resource, but all this resource ever did was
respond with "404" to everything.  Pretty dull resource.

But, I now think the "unmapped URL" is much closer to the idea I wanted to
capture by this term.

> > A lock-null resource is a null resource that has been locked.
>
> Or in the new phraseology, "a lock-null resource is an unmapped-URL that
> has been locked".
>
> Hmm, that doesn't sound right does it?  A resource is-a URL?

Now a lock-null resource would be a *resource* with:

* null (or undefined, take your pick) state
* properties as defined in 7.4

That is, by reserving the name, you have explicitly created a mapping
between a URL and some abstraction, whose state will be fleshed out later.

> And not _all_ unmapped-URLs (in DAV compliant namespace) can be locked.
> It seems that we need to augment "unmapped-URL" with "where the immediate
> parent exists".

Good point.

> > Since a lock null resource has state, I would claim it is a
> > resource. By the act of a client taking out a lock, they have
> > likely made a mapping of a URL to a conceptual resource, and
> > are int he process of fleshing out the computer representation
> > of the conceptual resource.
>
> Agreed.  Moving the server state of an 'unmapped-URL where the immediate
> parent exists' from no resource to a resource should, IMHO, respond with
> 201 Created.

This makes sense to me. My concern is that it would still be nice for the
first PUT after a lock-null is created to also return a 201.

- Jim

Received on Wednesday, 20 June 2001 19:52:03 UTC