ntpclient sanity checks

[Jason Schoon]

On 10/30/06, Mihai Buha <mihai.buha at nivis.com> wrote:
>
> > However, under some circumstances this is a non-compatible
> > change relative
> > to previous ntpclient versions, as I discovered trying to connect to a
> > badly maintained (by me) time server.
>
> If the incompatibility appears only when communicating with badly
> maintained time servers, then it's a Good Thing! The goal of NTP
> is to get accurate time, and well maintained servers presumably give
> better time than badly maintained ones!
>
> > My question to the group is, should these checks apply
> > optionally (when
> > selected with a new command switch), usually (unless deselected with a
> > new command switch), or always?
>
> Always! (minus Denis' objections). When people upgrade ntpclient,
> they expect it to perform better even (or especially) if this means
> rejecting bad servers. If they really want to get shot in the foot
> without knowing, they can always use the 2003 version. Of course,
> you should document it: "your old scripts should not break, but they
> still may, so test them".
>

Agreed with all of the discussion in the last message.  However, if it
doesn't muck up the code too badly, I think including a command-line switch
to enable backward compatibility would be good.  Definately default to
always using the newer stuff though.

If you go this route, you can setup a schedule for phasing out the older
support too.  Perhaps leave it as a command-line option this time, next time
perhaps add a warning about being deprecated, and the following release it
can be stripped away and cleanup the codebase.

Just some thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20061030/d1c80171/attachment.htm