[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: ntpclient sanity checks
From:       "Jason Schoon" <floydpink () gmail ! com>
Date:       2006-10-30 13:43:28
Message-ID: 78a54e1b0610300543j11f9de2agc846255c7b7f3aeb () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On 10/30/06, Mihai Buha <mihai.buha@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.

[Attachment #5 (text/html)]

On 10/30/06, <b class="gmail_sendername">Mihai Buha</b> &lt;<a \
href="mailto:mihai.buha@nivis.com">mihai.buha@nivis.com</a>&gt; wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> &gt; \
However, under some circumstances this is a non-compatible<br>&gt; change \
relative<br>&gt; to previous ntpclient versions, as I discovered trying to connect to \
a<br>&gt; badly maintained (by me) time server.<br><br>If the incompatibility appears \
only when communicating with badly <br>maintained time servers, then it's a Good \
Thing! The goal of NTP<br>is to get accurate time, and well maintained servers \
presumably give<br>better time than badly maintained ones!<br><br>&gt; My question to \
the group is, should these checks apply <br>&gt; optionally (when<br>&gt; selected \
with a new command switch), usually (unless deselected with a<br>&gt; new command \
switch), or always?<br><br>Always! (minus Denis' objections). When people upgrade \
ntpclient,<br> they expect it to perform better even (or especially) if this \
means<br>rejecting bad servers. If they really want to get shot in the \
foot<br>without knowing, they can always use the 2003 version. Of course,<br>you \
should document it: &quot;your old scripts should not break, but they <br>still may, \
so test them&quot;.<br></blockquote></div><br>Agreed with all of the discussion in \
the last message.&nbsp; 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.&nbsp; \
Definately default to always using the newer stuff though. <br><br>If you go this \
route, you can setup a schedule for phasing out the older support too.&nbsp; 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.&nbsp;  <br><br>Just some thoughts.<br>



_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]