RE: One lock per resource per person?

Lock tokens were also made unique so that we could use them across
resources. For example, I may want to say "Only make this change to resource
A if resource B is still locked."

There were two ways to do this:

Way 1 - Specifying a URI/identifier pair, e.g. If: <http://foo/bar,
ickygladsfyu>
Way 2 - Require the lock identifier to be globally unique, e.g. if:
ook:dldifjsojeferfoo/bar/ickygladsfyu

The problem with Way 1 is that if the URI of the resource is ever handed
over to a different system that system may not necessarily be away of all
the identifiers that the previous owner issued. This same problem exists for
E-Tags.

We considered this a flaw in the system and fixed it by using Way 2,
requiring that all identifiers be globally unique. Given how cheap and easy
it is to generate GUIDs we didn't feel the requirement was particularly
onerous.

		Yaron (who is NOT reading the group, really, I'm not, if I
were I would be screaming bloody murder about the horrors Jeff wants to
visit upon our lock design but I'm not reading the group, I'm not damn it!)

> -----Original Message-----
> From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
> Sent: Mon, October 18, 1999 2:50 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: One lock per resource per person?
> 
> 
> jw> The strongest requirement for globally unique lock tokens comes
> jw> from looking at the future where there could be multiple WebDAV
> jw> servers participating in a cooperative cluster.  In that case,
> jw> having globally unique lock tokens would prevent lock token
> jw> collisions.
> 
> Isn't this a quality-of-implementation issue?  If multiple servers
> need to access the same physical repository, a privately-arranged
> scheme can be used to keep them from colliding with each other
> (possibly even some server acting as a clearinghouse for doling out
> LOCK tokens).
> -- 
> bill@carpenter.ORG   (WJCarpenter)           PGP
> bill@bubblegum.net                    0x91865119
> 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>

Received on Monday, 18 October 1999 19:52:15 UTC