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 <gdt_at_ir.bbn.com>