<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 3, 2016 at 11:54 AM Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> One wonders, for example, why exactly one response (readstats) has a binary<br class="gmail_msg">
> payload<br class="gmail_msg">
<br class="gmail_msg">
My guess is history.  It's probably left over from before the mode6/mode7<br class="gmail_msg">
stuff got sorted out and Mills decided that mode6 should be all text.<br class="gmail_msg">
<br class="gmail_msg">
You could fix that.  I'd probably wait until there is a good reason to add<br class="gmail_msg">
another command.<br class="gmail_msg"></blockquote><div><br></div><div>At least for the time being, we want the Python implementation of ntpq to interop with NTP Classic.  And even if we manage to land a fixing patch on NTP Classic, we want to be able to interop with older versions of NTP Classic, at least until all major distros upgrade.</div><div><br></div><div>We're going to have to live with mode6 as it exists right now, for a while yet.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
One of the complicated responses sends the slots within a line in random<br class="gmail_msg">
order and adds a garbage field name and value.  The comment said it was to<br class="gmail_msg">
keep the client side from making assumptions that would turn into constraints<br class="gmail_msg">
on the server side.</blockquote><div><br></div><div>I've actually done that myself in code I've written in the past, pretty much for the same reason.</div></div></div>