On Fri, Sep 23, 2016 at 08:42:52PM -0400, Jan Harkes wrote:
> Coda 6.9.9 has been released.

Congratulations!

> - All said and done, this release has 4536 fewer lines of code and there
>   is still more where that came from.

Impressive work!

> Plans for the next release
> 
> - I've been reworking places where we relied on the assumption that a
>   server can be identified by just a single IPv4 address.

This is great.

>   Right now I think I will introduce a bunch of new RPCs that where
>   possible completely avoid using the PrimaryHost, and otherwise use an
>   identifier that is not linked to the server's IPv4 address. Then next

I assume you are intending to introduce an additional mapping
layer, A[AAA]-records for each server. Unfortunately I an convinced
that this layer would not carry any practically useful semantics.

You critisized hard our choice to use the internal server numbers
as the server reference for the clients - but actually this is
a totally internal server implementation detail [sic].

The clients can not know whether this "server id" corresponds to anything
inside the server/realm, they do not have or need any knowledge of the
server side implementation.

That's why I suggest, would you please consider using a pre-chosen
"reserved" server-id values which are given to the clients?
(Numbers or strings or something else does not matter)

Otherwise it will become another confusing and (no offence) meaningless
choice a realm administrator would have to do, in the same way as
for example choose the name of the root volume or the server number
for the first server in a realm - these do not carry any extra meaning.
Nor do the "DNS names for the servers", why let them to be choosable?

Without control over DNS in the zone corresponding to the realm name
Coda can not be fully deployed in any case. Coda admin should be
expected to be able to allocate SRV records as needed.

I suggest she should not be told to pick arbitrary names (thought for
A[AAA] records as you planned). What is the point with the choice?

Having avoided this quite arbitrary layer, the "servers" file would be
totally unneeded. Wouldn't it be a simplification to get rid of it?

>   year the old deprecated RPCs can be removed and we can move forward
>   with multihoming, IPv6, running servers on alternate ports and
>   hopefully more goodness.

Looking forward to IPv6 support!

I can not help noticing that the rest of the improvements you name
have been available in the code we run at Aetey and Chalmers for
quite some time.

We are happy of course to replace our code with a more compact and
more capable one whenever this will become possible.

Our main point of interest is not the code itself but Coda in efficient
system administration. That's why we care a lot about semantics in
the different configuration "knobs" and layers and want to avoid the
redundant ones, as much as you enjoy removing the dead code.

Thanks for your work Jan,
and best regards!

Rune