Wow, a reaction!

Thanks Jan!

I feared most of all that my letter would just get ignored :)

> > If there is anybody feeling that an arbitrary (or otherwise not "/") root
> > volume name is a must - please step forward and argue!
>
> Ok, let's say I'd like to provide a public root to machines that are
> connecting from outside of CMU and a private root for internal machines.

So you mean to undermine the whole idea of client-independent, global paths,
do you really? And why? Coda provides the straightforward means for access
management, acls and such.

> An alternative setup for this situation would be to use 2 realms, where

Again, it is not clear why you'd have to put the "external" and "internal"
data in different realms, as long as the data belongs to the same
administrative domain (i.e. it is you who rules, in both cases).
Just put it in different filetrees if you wish to distinguish?

> Another reason is that the actual rootvolume might have a (temporary)
> problem that makes it inaccessible. If this happens at a bad time the
> administrator could create an alternative root which allows users to
> access their data while the problems in the original volume are
> resolved.

In my very humble opinion it would be again a "wrong" fix for the problem.
A working "volume rename" operation would help in that case.

On the other side, a problem can hit any volume (and a crucial one) as
well. Then should we provide for GetFailoverVolumeName(primaryName) RPC ?
I'd either settle for "volume rename" - or such general
GetFailoverVolumeName which would be applicable to the root volume as
well :)

> Any arguments about avoiding the cost of this RPC can be ignored as this

Sure, I wanted just find *any* direct gain, even a very small one :-)
GetRootVolumename is not expensive in any technical sence, I just feel it
is unnecessary, and hence confusing.

> In a way clients 'ping' a server the first time they connect to a realm,
> this gives an initial and reasonably accurate feedback about expected
> network latency for rpc2,i the server processing time for this call
> should be near zero and constant.

Ok, let's explicitely use a NoOp RPC instead?

> Also because this call is guaranteed
> to return something and even works on a problematic server it provides
> debugging functionality. If getrootvolume fails, we must have a network
> or routing problem. If it succeeds we are most likely looking at a
> VRDB/VLDB issue.

Hmm, well, NoOp would be handy for this too!

> Just playing devil's advocate here,

I feel a bit strange about this small issue.
GetRootVolname is inexpensive, it works, it does not prevent us from
doing right things.
On the other side, it provokes some non-optimal things and hinders
analysis (as any unneeded stuff) hence hinders understanding.
That's what bothers me.

Thanks for your efforts Jan,
Coda is a great piece of software, and has become incomparably more mature
during the recent years - especially now, really global!
--
Ivan