How not to design a wire protocol

[Hal Murray]

Interesting, but...

Why isn't refclock_gpsd a good example?

Is there a good package for working with JSON?

I'm not convinced that NTP is a good example.   Sure, in hindsight, we can see 
some problems, but it's not obvious to me that JSON is the answer.  Are there 
any interesting alternatives?

The Daytime protocol (RFC 867) used ASCII.  Nobody uses it any more.

---------

The complexities of changing NTP's packet format are partly due to it's 
success.  If it wasn't so widely deployed there would be less pressure for 
backward compatibility.

Being able to change the wire packet format doesn't solve the problem.  You 
still have to write the code to do the right thing with the new format.

One of the areas on my list of hard unsolved computer science problems is how 
to upgrade a popular protocol.  It's usually easy to add new features.  It's 
hard to get rid of the old clients.  There is a chicken/egg in there.  If it's 
hard to get rid of them, then support lingers on.  If enough support is 
available there is not enough incentive for people running old software to 
upgrade.

Consider SMTP.  No binary packing there, but plenty of complexity and quirks.

--------

How much of this problem is changing skill sets?

I learned programming a long time ago.  Threads and byte swapping are no big 
deal.  On the other hand, I'm useless if you want a fancy web page with a data 
base behind it.

In the hardware world, it's generally understood that if you can do it in 
software, that will be cheaper than doing it in hardware.  (for almost all 
values of "it")  The key idea is that it's much easier to hire software people 
than hardware people.


-- 
These are my opinions.  I hate spam.