Subject: Re: One lock per resource per person?

From: [email-masked]
Date: Wed, 27 Oct 1999 09:48:33 -0400

What this implies is that a principal is really some unit of concurrent
processing. That's the only way update conflicts can occur anyway. However,
WebDAV specifies the principal as a (potentially) authenticated user agent,
which is not generally a process. Of course it could be, but this is
outside the scope of WebDAV. The current locking semantics leaves the
responsibility of managing current processing by the same principle with
the principle, not the protocol and server. The principle can use lock
tokens to distinguish applications that got the token by locking vs. some
other out-of-band means. The management of this is, and should be, outside
the scope of WebDAV. I would suggest that Gregs example would be better
handled by the principal wanting to distinguish locks by application A and
B using two different authentication aliases. We get the same function, but
the server doesn't have to get into the business of managing multiple locks
by the same principal. I also think this would make it easier for the
actual principal to manage concurrent access because the aliases can be
used to indicate what role he is playing in the potentially collaborating
applications. These named roles will be a lot easier to understand and
manage than opaque lock tokens handed out by the server.

Greg Stein <[email-masked]> on 10/26/99 10:06:51 PM

To:   Jason Crawford/Watson/IBM@IBMUS
cc:   [email-masked]

Subject:  Re: One lock per resource per person?

On Mon, 18 Oct 1999 [email-masked] wrote:
> This original question seems to have gotten lost in a tangent.  I'd
appreciate
> hearing more voices on this original issue which now is...
>
> "Can the two
> shared locks owned by the same principal be rooted at the same resource?"

I would say "absolutely."

Consider Application A and Application B, each running on the user's
machine, each wanting to take a shared lock on the particular resource.
(shared because the two apps can't use an exclusive lock)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: Greg Stein <[email-masked]>
Date: Wed, 27 Oct 1999 14:18:38 -0700 (PDT)

On Wed, 27 Oct 1999 [email-masked] wrote:
> the scope of WebDAV.

I think you're using semantics as an excuse here. I do not read the same
behavior from the spec (I see the same principle as being able to get
multiple, shared locks); therefore, I think you're stating it [as above] 
solely in a way to support your hypotheses.

> I would suggest that Gregs example would be better
> B using two different authentication aliases.

NO. As a user, I am assigned a *single* authentication alias on the
server. In an NT environment, it is my domain\username; in a Kerberos
environment, it is my login user/ticket; etc. There is no easy way for the
user to just "well, I'll use a second alias to differentiate these." That
is out of the user's scope and reliant upon the network/security
administrator. I *really* don't think the admin is about to say "well,
let's see... they're going to use up to three apps simultaneously against
our DAV server, so I guess that I'll create three users for this person;
oh wait, but what if they want to run four apps? I guess that I tell the
person they can't do that." The admin isn't going to do this for any
number of reasons.

And the user? There is no way they're going to go through a separate
authentication processes with the server simply to use more than one app
at a time. As a user, one of the best things that I like about Windows is
that it automatically supplies my credentials to servers -- that I only
have to supply them once. In the Unix world, I'm starting to change over
to ssh to get similar functionality, but still..

Cheers,
-g