Hello Jan,

My primary concern about multiple cells is to standardize a global view
of all coda cells like afs and dfs do, (possibly without having to have
a central coordinating entity like Transarc/IBM).

> is just how a client would interpret the 'magic symlinks' that indicate
> a volume mountpoint. i.e. currently I would mount a volume in the same
> cell as
> cfs mkm /coda/usr/jaharkes vmm:u.jaharkes

> and at some point I'd like to allow,
> cfs mkm /coda/usr/jaharkes-in-yourcell users/jaharkes_at_yourcell

Not that I meant! Rather globally seen
/coda/coda.cs.cmu.edu/jaharkes [-> #vmm:u.jaharkes
                                implicitely in coda.cs.cmu.edu]

Use /.coda/cell/ or /...coda/cell or something else just it being a
prsent on *all* computers having Coda, then /coda ->/.coda/this.cell/ is
ok - for a "traditional cell-local coda-view".

With other words keep files from different cells (different administration
units) separate in the filesystem, so that only cs.cmu.edu would be
allowed by the specification to create files under /.coda/coda.cs.cmu.edu/
or corresponding. Assure uniqueness of the branch names.

That is really important to be able to place files on Coda and be sure
about their global accessibility with the same name, semantics and
contents all over the world. If /[something]coda/ will contain different
things in  different cells, it ruins the possibility to have a stable
connection between /pathname/ and contents across administrative
boundaries.

No big deal whether it would be possible to mount foreign volumes at local
branches, I don't see why it would be very desirable. Ususal symlinks
provide for the same thing, without having foreign "meta"information in a
locally administered filetree.

Hope you understand what I mean. I find a global file view being a
*very* important reason for deploying either afs or dfs and would like
that Coda suits that criteria, of course.

I can go into details why, if you doubt.

Yours,
--
Ivan