Re: Status code for creating lock-null resource

On Wed, Jun 27, 2001 at 11:00:27PM -0400, Clemm, Geoff wrote:
> Now suppose UULs are not supported.  You can't issue a LOCK against an
> unmapped URI, so instead, you first create a resource *of the
> appropriate type* and then try to LOCK that.  This LOCK request may
> fail because someone already has a lock on that URI.  In this case,
> you either need to wait until that lock is removed (at which time, it
> is likely there is a resource mapped to that URI, but maybe not), or
> you need to try again on a different URI.

I am having trouble associating what I was going to say exactly with
the above, but its a bit of context...

I do not have a personal need for the following, but what about the case
where an application wants to create a temporary file with a new unique
file name. It does a 'LOCK' on a name. If it fails, it tries another
unique name. It keeps trying until it succeeds.

Without the current LOCK semantics, you would have to do a PUT to
create an empty file and then LOCK it. Does PUT have an OVERWRITE Y/N
flag? (I dont have the spec handy). If it always overwrites, then
there is the potential for a race condition.

Personally I would say tough luck. The above seems important in /tmp
or C:\temp etc, but not on a WebDAV file system. And there are lots of
potentials for race conditions in other parts of WebDAV arn't there?
(OK, so I don't actually know of any...) So why worry about one case
when it makes things so much more confusing overall?
WebDAV would be easier to implement if LOCK didn't have to create
these temporary amorphous resources that change their resource type
later (or even vanish complete).

Alan

ps: I like getting rid of the jargon "null resource", and like getting
rid of "lock-null" resources too *if possible*. Simplicity is a good
thing. If people are not implementing it correctly, there is probably
a good reason.

Received on Thursday, 28 June 2001 01:56:50 UTC