> 2) There might be a desire to make the transition from an NFS-based site
> configuration to a more powerful distributed file system such as Coda
> without initially having to deal with integrating the token acquisition
> process in a visible way to the user.  In such an environment (such as a
> set of servers using NIS and NFS -- common, I believe, in Intranet-style
> environments) a transparent changeover could be valuable.  This includes
> the initial token retrieval, and then later the problem of tokens
> expiring.

The way I see it ( the way to cause as few hedaches as possible ) is
have a user that can get tokens for other uid's.  All you have to do is
change the auth server to support this "super" user, then modify the
client to retrieve tokens as necessary for file access.  This would
allow non-interactive sessions to "grab" a token automagicly.  Most of
the real code changes would be in the client.

You could have a cron daemon go around every half-hour or so and clear
the token cache of any user that is not currently running processes.

This way there would be very little changes to the coda server system
itself.

Any comments?

-Eric