Refclocks and formatting

[Hal Murray]

esr at thyrsus.com said:
> If you mean changes to Mode 6, I'm not sure enough that shipping both hex
> and text would fix anything to we want to do it.  How do we know old code
> wouldn't barf on the following text?  Naive implementations in scripting
> languages would do that. 

If you look at the old code up a level from the detailed chunk that sends 
each field, you find that there is logic to scramble the order and send bogus 
extra fields.  The intention was to make sure client code didn't do the 
simple things that would break when fields are added.

So I think that old code will keep working as long as we keep sending the old 
fields without changing them.  Or at least any somewhat sane code.  I don't 
think we have to worry about the rest.


esr at thyrsus.com said:
>> Do we need to start tracking what we will support and/or develop
>> a policy for when we drop support for a slot?

> I've been obsessive about documenting visible changes; see docs/ntpsec.txt
> for them all.  There have not been many such things, and only one change in
> Mode 6. There's one context in which it ships a driver name rather than a
> number now. 

What I was trying to suggest was a list of the fields and which ones came 
from ntp classic (call it version 0.0) and which ones we added and which 
version we added them in and which fields they replace and/or have been 
replaced by and/or some policy about how long we support each version.

I'm assuming that we can add things to test them without a lot of discussion, 
but maybe we should think twice before we ship an actual released version 
that has them since that commits us to support for a long time.


-- 
These are my opinions.  I hate spam.