Recent trends in the codebase size

[Hal Murray]

fallenpegasus at gmail.com said:
> Is there a reason to keep dumbclock?   Maybe it exists as a starting
> framework for when someone wants to write a new clockdriver? 

It's not good for much more.

It's not clear that there is any good way to have a starting point reference. 
 If you give examples of all the possibilities, it will be too complicated.  
You can start with an existing driver.  That's easy if you already know your 
way around, but there is likely to be a lot of code that you have to skip 
over.

I won't complain if it goes away.

----------

> 2. If it were up to me, nobody would ever write an old-school refclock
> again.  Makes more sense to write a parse template for the generic driver.
> You get more code re-use that way.

I think that only works for hardware that fits the model.  There is a lot of 
stuff that doesn't.  Could you fit a SHM driver in there?  How about 
JSON/GPSD?

Ages ago, I looked into writing a parse driver.  I didn't get very far.  
Maybe because I didn't try very hard.  Maybe because the hardware I was 
working with wasn't a good fit.  Maybe because I got it going as a real 
driver and lost interest before I went back to work on the parse driver.



-- 
These are my opinions.  I hate spam.