[ntp:hackers] Cool new stuff

Sachin Kamboj skamboj at gmail.com
Sat Jul 22 09:54:13 UTC 2006

> sorry, but here is room for improvement :-)

And there will always be room for improvement ;-)
Lets always strive for more and more perfection...

> Usually this is handled in the syntax to expect a string token.

True... And if you check the parser's grammar (*), it does expect a string
token at a number of places...
The problem that comes up is that the existing NTP configuration file does
NOT expect or allow quoted strings. Possible alternative solutions to this
problem might be:

1. Use the existing NTP method with no quoted strings...
2. Use the 'C' method and force quoted strings wherever they are needed.
Anything that isn't quoted is an error.
3. Use both 1 and 2, with a switch that indicates whether we are using the
old NTP style string or C style strings. This can be used as a transition
4. Allow both 1 and 2 in a transparent fashion, with the code being smart
enough to figure out what is going on...

Method 4 is definitely the most user friendly. However, it goes against the
philosophy of keeping things simple and doing things the one "right way "
(the python approach).

Method 4 is also more like the perl way of having more than one way of doing
stuff. It also introduces subtleties in the way strings are handled. For
example what is the correct semantics of something like:


Is this valid? Is it one string or two? What about

"sdsada"asda" or dsadsa"dasda"sad" ?

Method 4 opens a whole Pandora's box of problems, where what it allows or
what is uses might fly in the face of what the user might expect. That might
go against the principle of least astonishment... Hence, my argument for
allowing only one thing and sticking to it.

Also method 4 might complicate the scanner code a bit... Not something that
can't be handled - I have definitely written stuff that is 100 times more
complicated, BUT it will be harder to make the resultant code clean AND

I'd probably be flamed to death for this, but I'd prefer approach 3, since
we already have a flag for old syntax and new syntax.

> tokenizer
> (flex) could pick up the string (including spaces and escape syntax
> handling).

As a side note, I am not using flex, because Prof. Mills insists (and I
agree) that we should not link against any external (non NTP) libraries, as
all platforms on which NTP is supposed to run might not have those libraries
available. Last I checked, any code generated with flex needs to link
against the flex library.

Hence, I wrote my own scanner from scratch that is not based on Flex styled
regular expressions.

Also for the stats keyword I would rather see a lexical token from the
> stats class
> which is dynamically configured at daemon startup time. This avoids to
> pre-define
> all stats classes fixed in the syntax.  This way  the dynamic
> registration of stats
> collectors is still possible without affecting the syntax. Think of it
> as a pre-registered
> list of allowed words at the place after the filegen keyword.
> register collector names, STRING being a quoted string holding the file
> name, ACTION
> being one of the action keywords, the rest are constant tokens)

Definitely possible... Again I am not sure that we will gain anything by
doing it this way. Is there any reason for allowing the kind of stats to be
configured at runtime? And why shouldn't this configuration be done in the
config file itself. I think I might be missing something here...

I would need to look at your grammar to give you more tips there.

Sure... I'd love to get more comments on the code. I will release the
grammar with the rest of the code shortly.

Thanks for all the comments...


(*) I know that you can't see the code yet.

Sachin Kamboj
Computer & Information Sciences
University of Delaware
Homepage: http://www.cis.udel.edu/~kamboj/
Life is a Constraint Satisfaction Problem.

More information about the hackers mailing list