On Mon, Sep 13, 2004 at 06:26:02PM +0200, Ivan Popov wrote:
> > know how such a partly disconnected state would work reliably and it is
> > possibly even more confusing to the end user.
> 
> I agree it _may_ be confusing - but not more than a sudden rights expiration.
> If the rights do not come back while disconnected, it makes the disconnected
> mode hardly reliably usable. If they do come back (as Venus behaves now), it is
...
> It may be hard to implement in a correct way, don't know.

The access rights should not come back when we go back to disconnected
state after a token got rejected by the servers. According to the code,
the cached rights are cleared when the token expires. The fact that this
doesn't seem to be working right is a good indication that it is pretty
hard to get anything in this area implemented correctly and to work
consistently.

But I can see what we can do. Maybe split up the code where we cunlog
(user triggered invalidation) from when the servers reject the token
(expiry/invalid token). My guess is that when the servers are reachable,
the client will keep trying to reconnect, and will get shot down each
time in an endless loop. So maybe an extra flag on the user object is
needed to tell when we want to get an authenticated connected for a user
who is using a rejected token so that we can fail before actually making
the rpc call. Although that again might trigger venus to consider the
servers unreachable for everyone until the next server probe comes
along.

Jan