- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 5 Jun 2001 18:48:03 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Lisa Dusseault [mailto:lisa@xythos.com] If somebody who's not supposed to, gets in and changes something in between a MKWORKSPACE command and a ACL request, that's a serious problem. Null resources help avoid that. It's not that somebody got their MKWORKSPACE request in ahead of mine --that's not the purpose of null resources at all. My point was not that a lock can prevent somebody from creating the workspace ahead of you, but rather that someone locking "your" workspace is no different from someone creating a workspace by that name before you can lock that URL. In particular, we are discussing two alternative sequences: LOCK/MKWORKSPACE/ACL/UNLOCK or MKWORKSPACE/LOCK/ACL/UNLOCK In the first sequence, the LOCK may fail (because there already is a lock on that URL), so you tell the user "that workspace is already in use by another user". In the second sequence, either the MKWORKSPACE may fail (because somebody got in and created a workspace before you) or the LOCK may fail (because somebody got in and locked the workspace before you). In either case, you still tell the user "that workspace is already in use by another user". So from the user's perspective, it doesn't matter whether or not their client did a LOCK/MKWORKSPACE or a MKWORKSPACE/LOCK. Their request can fail because another client "got there before them". Cheers, Geoff
Received on Tuesday, 5 June 2001 18:47:48 UTC