You're defending a lot of stuff I didn't attack. Almost everything you're doing sounds good to me, and I have no idea why you would think otherwise.
The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer".
I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, for the 80-90% case.
First, all functionality included, NTPD is presently 363.000 lines of .c and .h files.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
#define DEFPROPDELAY 0x00624dd3 /* 0.0015 seconds, 1.5 ms */
But doing this takes some code:
critter phk> ./ntimed-client -p pll_std_capture_time
Parameter:
pll_std_capture_time
Minimum:
2.000e+01
Maximum:
1.000e+06
Default:
3.000e+02
Description:
Capture time before stiffning PLL.
After this many seconds, the PLL will start to stiffen the P
and I terms to gain noise immunity. Decreasing risks that
initial frequency capture is not finished, which will increase
the offset-excursion. Increasing just delays this stiffning.
Failure: Stopping after parameter query.
I don't have a target size for the program, but 5-10.000 lines for a robust, reliable, secure and usable time sync client sounds reasonable to me.
... and that will still be less than 3% of the current NTPD.
I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.
I would guess that PHK, being PHK, is just being thorough rather than defensive. After all, if you can avoid a lot of back and forth, you're saving everybody time. Of all people here, he's definitely one of the ones worth giving the benefit of the doubt.
> aimed at being part of a larger family of time-keeping programs, like I intend to deliver
I am guessing that ntimed-client is intended for the 99.99% use case for most offices, homes and internet providers (which is client-server, not peer-to-peer), and that another program in the family will provide for your use case, which sounds very advanced to me.
The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer".
I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, for the 80-90% case.