(Illustration by Gaich Muramatsu)
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! RuneReceived on 2016-09-24 06:53:22