RE: Status code for creating lock-null resource

Yes, I think violent agreement is accurate description
of our attitude toward lock null resources.

The reason I believe backward compatibility is not
an issue here is that very few servers have
implemented the specified lock-null behavior (e.g.
auto-delete on unlock, or the ability to create an
arbitrary type of resource at the locked URL
(e.g. a collection by MKCOL).

Since there is no common functionality for lock-null
resources today, the only interoperable thing a
client can do today is to
create the resource first and then lock it.
So I'm just suggesting that we capture that interoperable
approach in the revised spec.

So I think we should just say "A server SHOULD fail
an attempt to lock an unmapped URL", and then remain
silent on what a server might end up doing if it lets
the lock of an unmapped URL succeed.  In general,
a MAY here is of little more use to the client than having
the protocol remain discretely silent, and the
benefit of using one of the several different
flavors of lock-null behavior is unlikely to warrant
writing special purpose code for each of those flavors.

Cheers,
Geoff

-----Original Message-----
From: Dan Brotsky [mailto:dbrotsky@Adobe.COM]
Sent: Wednesday, June 27, 2001 4:28 PM
To: Clemm Geoff
Cc: w3c-dist-auth@w3.org
Subject: RE: Status code for creating lock-null resource


So it sounds like you and I are in violent agreement about this: we 
both believe LOCK should simply create a no-content resource that's 
mapped to the URI and locked.  You seem to take the additional 
position that there shouldn't be any way for clients to request the 
"auto-delete on unlock" behavior.  It also sounds like you're 
suggesting that servers shouldn't be allowed to implement the 
"lock-null special method handling" or "auto-delete on unlock" 
behavior as a matter of policy, but (while I might agree this is not 
a good thing for them to do) I don't think we should be trying to 
legislate server policy (and it would be a hugely 
backward-incompatible change).

     dan

At 3:46 PM -0400 6/27/01, Clemm, Geoff wrote:
>I agree with point 0, but believe there is a much simpler
>answer to points 1 and 2.  In particular, we just define a LOCK
>on an unmapped URI as just being equivalent to an atomic
>PUT (with an empty body) followed by a LOCK.  No other special
>behavior.
>
>I am very much against making any of this behavior server-defined.
>That would just make the already difficult job of writing an
>interoperable client that much harder.
>
>And if I really could roll back time, I'd say: "LOCK on an
>unmapped URL just fails" (i.e. you can only LOCK a URL if
>there is a resource mapped to that URL).  If you want to LOCK
>a URL, you first have to create a resource at that URL to
>display the lock.  If some other client gets their
>lock in before you, that's no different from somebody today
>getting their lock-null resource created before you.  In either case,
>you have to either try your request again at some other URL,
>or wait until the other client releases the lock.
>
>Cheers,
>Geoff
>
>-----Original Message-----
>From: Dan Brotsky [mailto:dbrotsky@Adobe.COM]
>Sent: Wednesday, June 27, 2001 2:10 AM
>To: Tim Ellison
>Cc: w3c-dist-auth@w3.org
>Subject: RE: Status code for creating lock-null resource
>
>
>I'm definitely in the camp that thinks lock-null resources should go
>away in the next revise of 2518, and I very much like the way this
>discussion went, which I would summarize as:
>
>0. we don't talk about "null resources" any more, just unmapped-URIs.
>
>1. lock-null resources are just "regular resources" that are required
>to respond to certain methods in certain ways.
>
>2. creating a lock-null resource should return 201
>
>So far I would say a simple rephrasing might be:
>
>a. The result of a LOCK call on an unmapped-URI is that the URI gets
>mapped to a no-content resource that responds to certain (non-write)
>methods with 404 or 405.
>
>But the problem with this rephrasing is that:
>
>3. GET on the resource returns 404 or 405 not 204 (as would be
>expected for a "regular" no-content resource).  [Aside: 404 really
>makes no sense here, given that the resource is required to appear as
>a member of its parent collection - PROPFIND returns 207 but GET
>returns 404?  But that's a different issue.]
>
>4. OPTIONS and other non-write methods return 404 or 405 for no
>particular reason.
>
>5. UNLOCK on the resource returns the URL to an unmapped state.
>
>Note that restrictions #3 and #4 are unmotivated, as far as I can
>tell; the only "special" aspect of this resource (aside from #5) is
>that the server really can't know whether it's a collection or not.
>[Aside: The DAV:resourcetype property really needs another value in
>these cases, such as "indeterminate".  But that's another issue.]
>
>Which brings us to #5: UNLOCK (essentially) deletes the resource.  I
>think I understand the motivation for this: a client that locks the
>URI but then decides not to write it doesn't want to have to do a
>delete in order not to leave an empty resource mapped to the URI.
>But my problem is that the spec *mandates* this behavior, rather than
>leaving up to the server (or allowing the client to request it
>specially as part of the UNLOCK).
>
>Essentially the spec is requiring that a LOCK/UNLOCK combination with
>no intervening write operations do *nothing* to a URI or the resource
>mapped to it.  (This is a mandate that has been picked up in deltaV,
>as well.)  But while I can understand that servers might want to work
>this way, and that clients might want to request this, I can see no
>reason to mandate this.
>
>In fact, my experience with building workflow and document-management
>servers leads me to entirely the other conclusion: servers need the
>discretion to interpret LOCK as a statement of intent in the
>workflow, one that an UNLOCK does not necessarily "undo."  In
>particular, LOCK is the only way in WebDAV for a client to create a
>no-content resource (as opposed to one with content-length 0), and
>just because the client doesn't create the content before unlocking
>doesn't mean that the client wants the created resource (and live
>properties such as its creator) to be expunged from the server.
>
>As we revise 2518, I think we should give servers much more
>discretion about how they handle LOCK/UNLOCK pairs, and possibly we
>should give clients a way of indicating in the UNLOCK that "the lock
>was a mistake, undo it if you can" (much as deltaV allows undoing a
>checkout).  If we do so, I think lock-null resources (and their
>concomitant problems) can be done away with completely, and LOCK can
>simply be seen as creating a no-content resource when applied to
>unmapped URIs.  Servers who wish to preserve the lock-null kinds of
>behavior for those resources are welcome to, and they will still be
>in compliance with the spec.
>
>      dan
>--
>Daniel Brotsky, Adobe Systems
>tel 408-536-4150, pager 877-704-4062
>2-way pager email: <mailto:page-dbrotsky@adobe.com>

-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Wednesday, 27 June 2001 17:21:46 UTC