RE: Locks and loopback bindings

The major reason to not change standard behavior in the way Jim suggests
is that this will break existing clients.  In particular, if a user depth
locks a collection, a standard depth locking client will assume that the
lock token will apply to all the members of that collection, and will pass
that lock token in any edit request the user makes to a member of that
collection.

But with the semantics that Jim suggests, some of those members will 
remain
mysteriously unlocked, and the editor just fails with "unexpectedly 
missing
lock" when the user attempts to edit (or even worse, allows the user to 
edit
an unlocked resource, without overwrite protection). 

Now let's contrast this with the scenario Jim describes.  Surely any 
server
that is bold enough to support both binding loops and depth locking would
support the DAV:lockroot property introduced a while ago to solve exactly
this problem of not knowing where a lock comes from.  This means that
neither Bob nor Alice is ever surprised or mystified about an "unexpected
lock", because the DAV:lockroot says exactly where it came from.  And if
they want to discover the path back to the lock root, they just use the 
parent-bindings property to walk back through the locked parents until 
they
find the root (or if they have a civilized client, their client will do 
this
walk for them, and report the path from the lock root to the locked 
resource).

So "overlocking" is always easily explained, and is the expected behavior 
for existing clients, while "underlocking" is both mysterious (how does a
user use a standard client to discover why the member isn't locked?) and 
more
significantly, will break existing clients that expect the standard depth
locking behavior.

Cheers,
Geoff

Jim wrote on 12/07/2004 07:32:47 PM:

> 
> > I'm still not sure why you call that a "problem". As far as I 
> > can tell, it works exactly as designed.
> 
> Here is a plausible scenario that outlines why I think this is a 
problem.
> 
> Assume there is a collection hierarchy rooted at a collection with
> non-unique pathname /collA/collB/collC/collD. Within this hierarchy 
there is
> one loopback binding to /collB/, one of approximately 500 bindings 
within
> the collD hierarchy. There is only the one loopback binding in the 
entire
> collD hierarchy.
> 
> Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants 
to
> ensure she can make changes to multiple documents to ensure their 
contents
> are consistent with one another. (Alice should probably be using DeltaV
> workspaces for this, but that's another matter). So, Alice depth locks 
the
> entire hierarchy, by submitting her lock request to
> /collA/collB/collC/collD.
> 
> Bob knows that Alice is working on /collA/collB/collC/collD because they
> talked about her doing so at their staff meeting in the morning. So, he 
was
> surprised to discover that the area where he was supposed to work,
> /collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked 
her
> why she had locked his work area, and Alice replied that she hadn't, and 
was
> confused as to why Bob thought this. Bob replied that his authoring tool
> reported her as owning the locks on those resources, and that she had 
locked
> his entire resource space.
> 
> Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good 
thing
> DAV Explorer automatically retrieves and applies the lock token it finds 
in
> the lockdiscovery header, otherwise Bob and Alice would really have a 
hard
> time :-) However, she's then confused as to why the locks on her 
resource
> space have disappeared. So she locks /collA/collB/collC/collD, only to 
find
> out that she can't take out the lock anymore. Frustrating. She asks Bob 
if
> he was able to take out a lock. Yes, he says, now I'm able to take out 
the
> lock and work.
> 
> Strange, thinks Alice, it's as if the system only allows one of us to 
work
> at a time. Not understanding what is going on, and have received no 
error
> messages from her software that would lead her to think that a loopback
> binding is causing the problem, she calls her firm's technical support.
> Since most existing hierarchy browsers for WebDAV do not give any 
visibility
> into loopback bindings, it's anyone's guess as to how long it will take
> technical support to determine the root cause of the problem.
> 
> - Jim
> 
>