On Mon, Jun 02, 2003 at 10:38:41AM +0200, Ivan Popov wrote:
> On Mon, 2 Jun 2003, Florian Schaefer wrote:
> > after having installed the new client here there is this new realm
> > directory in /coda. But how do I get my old layout back?
> The old layout was limited, it had no place for multiple cells,
> the new one *is* better and has no new limitations except that you paths
> have changed.

Other advantages of the new scheme,

- Impossible to get a conflict on /coda, so the special /coda/.CONTROL
  file which is used by cfs, clog, and hoard will always be reachable.
  So a conflict on the root directory of your cell is now actually
  repairable without needing to play around with temporary rootvolumes
  and such.

- More reliable mounting of /coda by venus. The client no longer needs
  to contact the servers to get the attributes of the /coda directory.
  As a result startup is slightly faster, and more importantly this
  protects venus startup from possible network or server problems when
  people are new to Coda.

- There really is no local client configuration. A user simply drops in
  the rpm (and kernel module) or could 'borrow' some laptop with
  pre-installed Coda and should not need any changes to reach his files.
  Again helpful during initial setup, because someone can start a
  client, connect to testserver.coda and try to reach his own servers
  without going through the reconfigure/reinit/remount steps.

Clear disadvantages

- Longer pathnames. Tab completion helps here a bit.
- Existing users have to get used to the new names.
  I actually added a 'usr' entry to the realms file without any server
  names. This is basically a 'negative entry', informing the client that
  this realm definitely does not exist. (I kept typing /coda/usr/, and
  Coda would try to resolve the IN SRV entries for _codasrv_udp.usr.)
- Similarily existing applications need to be reconfigured to use the
  new paths.

> As a temporary and hackish workaround you might be able to do:
> 
> ...../realms file:
> florian     floyd.netego.de      (or what your servers are)
> texmf.local floyd.netego.de      ( ------ " ------ )

Tread very carefully. You can reach a realm through different names, but
this is not reliable, as the servers don't realize that the client is
accessing files from a different context. As a result, the server only
sends callbacks back to one 'instance' of the realm and the other
instances will show some stale and invalid state until we reconnect to
the server.

This can be fixed on the server, but it needs some shuffling in the
connection handling and I wanted to keep the server changes as minimal
as possible.

The realms file really should be used as little as possible, it is only
provided as an alternative if you happen to use multiple root servers
and can not add IN SRV records to your DNS namespace. Also realm names
are intentionally fully qualified domain names. I know that with AFS
there are typically local shortcuts. For instance, at CMU people can use
/afs/cs to access the /afs/cs.cmu.edu realm, but those shortcuts depend
on how the local root volume was populated. Because we do not have such
a centrally administered rootvolume, but depend on DNS information this
would end up pretty confusing for users that take their laptop to a
local coffeeshop where due to the DHCP settings the fqdn expansion of
'cs' would suddenly become 'cs.coffee-isp.com', instead of 'cs.cmu.edu'.

Jan