Fri Aug 16 08:59:55 EDT 2019
Protocol oriented programming
I now know exactly what I mean by this:
- printing is easier than parsing
- buffers to the rescue: do "macro expansion" at the transmitter end
Essentially, protocol units should be easily interpreted scripts.
What is interesting is that buffering is used to perform some kind of
macro expension at the transmitting end. Often this allows the
receiver to be a fairly direct script interpreter that does not need
to keep a lot of state and/or resume points, which can often be
Otoh, with sufficient buffering, the receiver can be "timesliced" at
protocol boundaries. I.e. no resume points are needed to create a
So there are other ideas:
- Avoid task switching mechanisms by working on complete units at both
ends: sender dumps into buffer, receiver polls for a single atomic
command at a time.
- Trade buffer memory for receiver complexity.
The latter is an interesting mechanism: macro expansion / inlining at
the sending end, or subroutine calls at the receiving end. The latter
requires state, the former just requires buffer space.
It is interesting that for low-level code, designing things such no
intermediate state needs to be saved can make programs a lot simpler.
The basic idea is to replace state machines with instruction-fed