Re: token-less lock-discovery

>  Well, thanks for the warning. Which server(s) would that be?
I don't know if there are any now.  Perhaps someone will speak up.  I doubt
a server would be configured this way by default, but I wouldn't be
surprised if some were to be configurable in this regard so as to leave it
up the administrator to deal with situations local to his sites if the need
develops.   The spec left this option open intentionally for the reasons
described in section 7.6.

<<
And will
they prevent a client application/operating system/network connection
from crashing or will they have another method to discover locks and
unlock resources?
>>
Of course not.  The thinking was that problems of the ilk you described
could be addressed in several ways:
1) the locks can time out
2) the server administrator can break a lock
3) a client can store it's lock tokens persistantly in what they deem to be
an adequately secure fashion.

The the most compeling case against it was the case of clients who store
their tokens locally and whose users switch between machines (home vs work)
often and know their applications won't interact in bad ways.  ("Drat! I
left my token on my office machine! I really want to put my updated file
back on the server! Grumble.") There are of course ways around this, but
it's doubtful that these approaches would be used.

I believe that's pretty much the history and it answers your question.

My thinking is that section 7.6 might be a red herring and this last case
certainly can be common.  But we did leave the final decision up to the
server developer and administrator.  I personally feel the behavior you
expect should be the default.  But I also believe that administrator should
be able to configure this if they discover there is a need to hide the
tokens.  I also believe that clients should not be written to be dependent
on the visibility of the token.

So what are clients to do?

In your case, you could probably use an IF header in a quick benign
operation to determine if the lock is still there before you do the
expensive operation.

In JimW's case, he just needs to make sure his client doesn't do anything
if the lock-discovery doesn't reveal the token.

And generically client apps should request appropriate lock timeout periods
and keep a persistant vault of their tokens if they feel they or their OS
are prone to crashing.

BTW... this topic is a tangent and not the reason I asked my original
question.  :-)

J.

Received on Wednesday, 27 June 2001 13:54:12 UTC