W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Deleting versions

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 5 Jun 2001 16:43:02 -0700
To: "Clemm, Geoff" <gclemm@rational.com>, "DeltaV" <ietf-dav-versioning@w3.org>
The problem is that the "client that got there before them" may have
permission to alter a workspace, but they may NOT have permission to CREATE
a workspace.

The problem is not that the other client locked it, but that they might
apply changes before you get a chance to prevent them!  I create a Workspace
(or a resource, or a collection).  I want to then set the ACLs so that I'm
the only one that can alter this resource, because it's MINE.  But, in
between the MKWORKSPACE and the subsequent LOCK, the other client comes in
and sets ACLs so that they can write the workspace and I can't!  Ouch.

Null resource went through similar discussions, and was kept for reasons
which apply to MKWORKSPACE the same way they apply to PUT, MKCOL.


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, June 05, 2001 3:48 PM
> To: DeltaV
> Subject: RE: Deleting versions
>    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:
> or
> 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 19:44:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC