Re: DELETE leaving a lock-null resource; was LOCK Scenarios

OK, now that the new versioning protocol draft is out the door,
time to get back to locking (:-).
I'll try out the: "Simplified RFC-2518 Locking, Version-2" proposal
against the issues raised here.
 From: ccjason@us.ibm.com
 <gmc/>
 .... The server is responsible for
 retrieving the same resource whenever the client gives it a URL
 and a lock token (think of it as a private binding that the server
 keeps around).
 <jc/> Geoff, I think Jim's point was that the same lock could have been
 rooted at many places over the course of time as it has moved. In
 fact due to multiple bindings and such... we've added even one more
 multiplier to the size of the list that needs to be maintained. His
 question though was how long does the server need to maintain it. I
 guess the server/lock would need to remember all of it's URI's until
 the resource is eventually UNLOCK'd.
<gmc/> The server has to remember the association of a lock token with a
particular resource. Since this is the server, it doesn't need to
use some URL ... it just keeps a handle on the resource that
is independent of the http URL space.
 <gmc/>
 The server could do this by just refusing to MOVE
 or DELETE the resource (as is required by the current 2518 draft),
 or by just remembering what resource is associated with that
 <URL, lock-token> pair. All we are doing here is giving the server
 some additional flexibility in implementation that was constrained
 by the current language in 2518.
 <jc/> I see. So the proposal is that a server either to protect the
 URI... or to maintain a way for a client to follow where it moved
 to... and you're proposing the mechanism to do the latter.
 Interesting. It could be a market differentiator. It would mean a
 bit more complexity for the client to support either type of server
 though. Not much though. I think if the client supported what you're
 proposing, they'd also work with a system that does URI protection.
 They'd just wouldn't execute the code that deals with what happens
 after a remapping.
Right.
 <jc/> Also note: in the presence of depth locks... zillions of
 resources can be locked. I don't think this necessarily increases the
 size of the list of lock URI's maintained since I believe only the
 URI's of the root of the lock need to be maintained... but it does
 mean that the resolution algorithm has to be more sophisticated since
 it would also need to remap the URI of child resources also.
And if we do not support depth locks, the issue goes away completely (:-).
 <jc/> This means that a client must submit lock tokens with GETs and
 PROPFIND's just to insure it gets redirected when necessary. No
 biggie I suppose.
<gmc/> Right. The client uses the lock token for all requests on a
locked resource, rather than only using them for requests that might
update the locked resource.
 <jc/> I'm not sure this would work well with clients that seperate the lock
 action from subsequent actions on the locked resources. That is, a
 human is running the client code. The human requests the locks. Then
 a human requests various actions on resources that "just happen to be
 locked". I guess that whenever the human requests an action on a
 resource, the client application would just need to make a point of
 finding all locks that apply to a resource... even if inherited... and
 submit them with the request. I guess this sort of client app often
 would have to do this anyway, but now they must also do it for
 PROPFIND and GET also. Okay, no biggie.
<gmc/> Also note that a human would always need a client doing the real
work in a locking context, since it is unlikely that a human ever would
or could remember the lock token strings that are needed to work with a
locked resource.
 <jc/> It also means that I believe for the first time in WebDAV,
 it actually becomes functionally important to specify the URI at
 which we think a
 lock is rooted when we submit the lock token.
<gmc/> Without depth locking, the lock token is all that is needed.
 <jc/> If someone does a MOVE... and all the tokens
 of all the would-be protected URI's are submitted, the server doesn't
 need to maintain a remapping list because the client already knows
 which locks have lost those mappings. It's only the URI's for locks
 for which no tokens were submitted that the server needs to remember
 the remapping. This might provide for more efficient operation.
<gmc/> If the server just keeps track of what resource is locked by
a particular lock token, then remapping just consists of returning
a valid URL to that resource in a 302.
 <jc/> A lock can have many mappings and a single operation can delete
 multiple mappings of a lock. Previously we said that each lock had a
 particular URI that was protected... and only when that URI was moved,
 did feel compelled to do any kind of lock remapping. Although we
 could probably guess, t now claim to know what lock mapping(s) the
 client really cares about. None are more privledged. I think the
 previous paragraph has to be modified to state that if any of these
 locks have other mappings than the mappings submitted with the token,
 then all of those others that are broken by an operation need to go
 onto the remapping list for that lock. Is this really *required*? I
 think technically yes... but probably not in practice. The client
 probably only knows a lock by one mapping... and it will be the one
 that the client will submit.
 Protecting a URI is sounding easier. :-)
<gmc/> Associating a lock token with a single resource until
it is unlocked is probably even easier (:-).
Cheers,
Geoff

Received on Saturday, 23 October 1999 11:57:03 UTC

AltStyle によって変換されたページ (->オリジナル) /