- From: Dan Brotsky <dbrotsky@Adobe.COM>
- Date: Thu, 28 Jun 2001 00:30:04 -0700
- To: w3c-dist-auth@w3.org
At 11:00 PM -0400 6/27/01, Clemm, Geoff wrote: >Dan has lots of good stuff in this message that I'll want to >follow-up on, but I first wanted to focus on one particular >comment: > > From: Dan Brotsky [mailto:dbrotsky@Adobe.COM] > > Geoff is suggesting something slightly different: that LOCK not > even be allowed on unmapped-URIs. This also gets rid of LNRs and > has the advantage that you always know whether something is a > collection or not. However it doesn't allow users to > simultaneously create and LOCK resources for further editing, which > bothers me. > >Could you expand on why this bothers you? There are actually three reasons: 1. Because it sets you up for ambiguity and race conditions by breaking a single user-conceptual operation (beginning to edit a new resource) into two protocol operations (PUT and LOCK). A client that wants to create and edit a new resource will go through a conventional sequence such as HEAD (to verify the URL as unmapped), PUT (to create the resource), and LOCK (to reserve the resource for editing). This conflicts not only with itself but with the conventional sequence for editing an existing resource is LOCK / GET (LOCK first to make sure the GET content is the latest content). This gives rise to two canonical problem cases: a. If I'm creating and editing a new resource, and you are editing a resource but specify my name by mistake, then my client has to deal with the unexpected (and meaningless at the user level) case where I successfully create the resource but then can't edit it, and your client has to deal with the unexpected (and meaningless at the user level) case where you open a resource to edit it only to find that it's empty or doesn't contain anything like what I was expecting. b. If we're both trying to create and edit the same (new) resource, and my PUT precedes yours but my LOCK follows yours, then once I've obtained the LOCK I find that the etag on the resource is different than the one I got back from my PUT. This is the canonical client-side warning sign that I'm in a race with someone else, and I have to stop and make sure that I pull down the current content. At that point, unless you and I were using the same "template" resource in our initial PUTs, I've got a real problem. I either have to blow away your edit (which I'm not entitled to do under normal circumstances) or I need to give up my lock. But by then your LOCK has failed, so you've figured out that someone else is creating the resource and you've given up. (I have observed both of these scenarios in existing graphic arts workflows, by the way. There are many workflow systems in use that have exactly this kind of problem.) 2. Because there's no well-defined way for PUT to reliably create a no-content resource, which is the kind I claim you want to be creating when you're creating a new one but don't have content for it yet. Most servers given a PUT of 0 length create a 0-length resource, which is quite a different thing than a no-content one. 3. Because doing a PUT and then a LOCK and then (eventually) another PUT forces you to make *two* updates to the resource rather than one, and the controlling server may not actually want to authorize that. (For example, workflow servers often want to send things off for approval, etc., each time they are updated.) > Since (I believe) this is >the only thing that you gain with "unmapped URI locks" (UULs, >previously known as LNRs :-), it is important to understand why (or >whether) this matters enough to warrant the kind of confusion and >complexity that UULs bring to the model. > >Suppose UULs are supported. If you issue a LOCK against an unmapped >URI, this 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. Don't get me wrong: I am as opposed to UULs as I am to LNRs! >Now suppose UULs are not supported. You can't issue a LOCK against an >unmapped URI, My proposal is that you *can* do this, but the effect is that a no-content resource is created and bound to that URI. > so instead, you first create a resource *of the >appropriate type* and then try to LOCK that. The big differences between this proposal and yours seem to be: 1. The initial content of the resource (none) is fixed. 2. The resource can be made a collection via MKCOL. 3. There's no chance of race conditions. > 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. > >Those two cases look very similar (in fact, I copied the text >of the first case into the second case, so they should look >*really* similar :-). So what do you really gain with UULs? See above. I think we're very close. >Note: for compatibility with old 2518 servers, we shouldn't say that a >LOCK MUST fail on an unmapped URI, but we certainly could amend the >protocol to say that it SHOULD fail. Since UULs act so differently on >current servers, this is probably the only thing we could say, if we >wanted to tell client writers how to achieve interoperability with >existing servers. In my proposal, there is no incompatibility with existing servers, because the LNR they create is a no-content resource (or would be, if you were allowed to do a GET :^), and you can still issue a MKCOL. So let me ask you the converse question: You seem to be worried by the fact that we don't know what kind of resource (collection or not) the new resource is going to be. What's the problem with letting the new resource start out as a no-content non-collection and then be made into a collection? Note that in both of our proposals the same requests are made---either a PUT or a MKCOL and a LOCK. It's just that in my version the LOCK comes first (a la the LOCK / GET sequence that initiates an edit). And in my version the client doesn't have to figure out whether the resource exists before initiating the sequence: all edits (of both existing and new resources) start out with a LOCK / GET, and in the case of the create the LOCK comes back with a 201 which tells the client that the GET would return a 204 (and thus there's no reason to issue it). dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Thursday, 28 June 2001 03:38:35 UTC