Hal Murray via devel <devel@ntpsec.org>:
>
> Gary said:
> > I think he is referring to reecent proposals to split ntpd up into multiple
> > daemons. Daemons for the core, NTS, clients, etc. Each doing a small job.
> > Rather than the one big daemon we have now.
>
> That sort of split looks good on paper, but I'm not sure how well it would
> work out in practice.
I share Hal's skepticism.
Back at the beginning of this project I had a plan to split ntpd in
two. Isolate all the network plumbing in one half, all the clock
management in another, have them communicate over some kind of local
channel. Why I eventually gave it up is instructive.
Any time you split up a progream like ntpd you add to the total volume
of code, if only because you now need two network wrapper layers around the
core logic rather than just one. This can be worth doing, but only if the
payoff in reduction of global compleity due to decoupling the core
pieces is high enough to pay for the extra code.
You cannot take for granted that this will be so, and I eventually
concluded that it was not - we were collecting much bigger
simplifications simply by removing obsolete drivers.
Another headache is service configuration. Woul;d the two pieces have
shared the same config file or not? Complications would have arisen
either way. If you split the file it's a flag day for all users (no
small matter when the uservase is as conservative and risk-averse as
ntpd's). OTOH, if you don't split the file you lose some of the
simplification you might have collected, as both pices have to carry
the same parser and generate errors when ry're fed a piece of
configuration that's not theirs to handle.
Thus, weaing my architect hat, I'd have to see a very strong and specific
case for splitting up ntpd before I'd agree.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
