I think the historical view that resulted in LNR's is as follows: * There are valid scenarios where clients want to create a resource and lock atomically, or create a collection and lock atomically * We can't handle this for regular resources since we can't change PUT, although we could solve this for MKCOL My suggestion is built on Lisa's suggestion: * Make LOCK create empty resources (with length 0) that are real resources if the URL is not mapped and a special header is specified (say Create: true, kind of like the O_CREAT flag on open() on Unix) * Make MKCOL take a header specifying that a lock should be granted as well, like Lock: true I've always had a viceral negative reaction to creating gratuitous empty files, but on retrospect I think this comes from working on versioning systems where this would create a useless version that the customer doesn't want. In this case, since a deltaV content creation client would probably do: * Open --> LOCK / Create: true * Save --> PUT followed by VERSION-CONTROL followed by UNLOCK so there is no problem of an extraneous version. --EricReceived on Thursday, 28 June 2001 14:03:46 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT