RE: Notes from DAV meeting

   From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]

I agree with all of Shaun's comments, except for:

   > - Lock Permissions -
   > Consensus around: Users other than lock creators MAY be able to
   > UNLOCK a resource by discovering and using the correct lock
   > token.

   Assuming your are referring to "ordinary" users i.e. not say when
   an Administrator removes a lock because an employee has left the
   company sort of thing:

   I strongly disagree with this. It should not be allowed at all.

I strongly agree with the consensus opinion.

A client holding a lock already has to deal with locks being lost
through timeouts.  Allowing another client to effectively force the
timeout is a valuable feature that does not increase the complexity of
the locking client.  A server can use access control to control what
users have permission to force the timeout.

   I know locks can disappear at any time, but it could cause problems
   for example ...

Any such problem already occurs because of timeouts, so clients have to
deal with all these situations anyway.  Allowing a client to force
a timeout decreases the need to have an automatic server timeout,
and therefore this capability will actually decrease the number of
unnecessary timeouts (since the server can be written to assume that
timeouts will be forced by clients that need them).

   > Servers should never allow users other than lock creaters to
   > update a locked resource, even if they use the correct lock
   > token.

   I know what this statement is meant to mean, but one could say this 2nd
   statement contradicts the 1st because the new lock creator is not the
   original lock creator.

The "update" here means "update the content or dead properties".
An UNLOCK does not update the content or dead properties, and therefore
these two statements are consistent.  The term "update" could be
clarified, to make sure there is no misunderstanding.

   After all, look at the confusion "null resource" caused.

I don't see the relationship between forced lock timeouts and null
resources.

Cheers,
Geoff

Received on Wednesday, 15 August 2001 09:47:02 UTC