Re: One lock per resource per person?

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 <gstein@lyra.org> on 10/26/99 10:06:51 PM

To:   Jason Crawford/Watson/IBM@IBMUS
cc:   w3c-dist-auth@w3.org

Subject:  Re: One lock per resource per person?



On Mon, 18 Oct 1999 ccjason@us.ibm.com 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/

Received on Wednesday, 27 October 1999 16:31:00 UTC