jh> Finally we try to connect to the found servers, and if the
jh> connection setup succeeds an entry for the newly discovered
jh> realm is dynamically created in the /coda directory.
Damn. This means that you _must_ be connected to start Coda, then go
disconnected without ever shutting venus down, right? That would be
consistent with the fact that if I start venus, bring the network up,
do "ls /coda/realm", and then shut the network down, I have no
problems. (I have this vague impression that "ls /coda/realm" may not
even be necessary if I gave it a few seconds, maybe the hoard daemon
is pinging the server?)
I will offer the following behavior as a 'requirement' for coda
usability:
If one starts venus without network reachability[1], then
cached/hoarded files can be accessed.
A uid that has previously (in a previous venus invocation, unless an
explicit cunlog was done) had permission to access files should
continue to be able to access them. In other words, a mapping from
uid to coda user/group should persist indefinitely (in RVM) for venus.
[1] such as if one's box crashes or is power cycled when away from
the net.
The basic point is that you should be able to read the cache and make
disconnected changes, even if you start up disconnected. Obviously,
venus will had to have talked to the servers since it has been
re-inited (but this is very different from restarted).
This probably leads to a need to either separate the mapping of realm
name to IP and realms to cached objects, or to retain the mappings
across invocations, perhaps trying to update them periodically.
--
Greg Troxel <[EMAIL PROTECTED]>
