RE: Locking questions

> <jra>
> But there may be many shared locks in the lockdiscovery 
> property. How would an
> application figure out which one was the one just created for 
> this user? I see
> that it works with exclusive locks because there can only be one.
> </jra>

So we agree that we can always resolve the proper lock token for an
exclusive lock, the question now is how to handle a shared lock. I believe
that the core of your misunderstanding is that you believe that when a
shared lock is issued there will be multiple lock tokens for each owner of
the shared lock. That is not the case. A shared lock has one and only one
lock token assigned to it, regardless of the number of owners. Thus if you
ask for a shared lock and you get back a successful result then you need
only examine the body to find out which entry describes the shared lock you
asked for (by definition there can be only one) and you know which one
identifies your lock token.

A further legitimate issue is how to identify your lock in the case where
you have "lost" your memory. Again the owner header can be useful here.
Shared locks are free to add multiple entries inside of owner so a client
can always recognize its own owner entry.

However I certainly believe that the world will be a better place when the
standard principal identifier is agreed on by the ACL types.

> <jra>
> But DAV did specify Basic (with SSL) and Digest authorization 
> schemes must be
> supported for security. They both provide the principal 
> userid. Couldn't this
> be used?
> 
> Next, the temporary hack couldn't be relied upon as not all 
> servers would
> necessarily do it the same way.
> 
> So I still don't see how an application can get the lock 
> token from the lock it
> just requested.
> </jra>
> 

However SSL uses a completely different principal identifier (a
certificate). Rather than try to shoe horn a "universal" principal
identifier we decided to punt the problem to the ACL group.


			Yaron

Received on Tuesday, 14 July 1998 20:19:27 UTC