Re: resourcetype locknull

gmc> So I'm back to:
gmc>    - return a 404 if there is no resource to LOCK,
gmc>    - let the client create a "null" instance of what it wants there,
gmc>    - then the client locks that null instance and it is off and running.

1.  There is a Very Popular Client which does just about this when
creating a new resource.

2.  The main problem with "lock null resources" is that the spec is a
little weak on exactly what they are.  That causes me as a server
implementor to try to think too hard, when instead I could be having a 
delicious latte on the veranda.  To my mind, this really reduces the
chances of most servers ending up with compatible semantics for this.

3.  OK, how about this implementation?  I grant "lock null resource"
requests, but my server has discretion to vaporize the locks whenever
it wants, and it wants to vaporize them one clock tick after it
creates them.  Bwahh-ha-ha-ha!  Take that, pesky clients!  :-)

4.  I run a lot of applications every day that work with my local
filesystem, and they seem to cope without the equivalent of "lock null
resource".  If there is a namespace collision, which there often is,
I, as a user, deal with that (including the occasional walk to educate
Wally in the next cubicle).  It's an everyday occurrence.  That's what
open() with the O_EXCL flag is all about, right?  Could it be
paralleled in WebDAV with either (a) expanded use of the OVERWRITE:
header, or (b) HTTP/1.1 PUT, etc, with "IF-NONE-MATCH: *"?
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

Received on Thursday, 14 October 1999 13:25:38 UTC