Sun May 5 20:30:46 EDT 2019
For internal communication between systems that are very different, it
is often useful to use assymetric protocols, where each communication
direction uses a different data encoding.
I used to think this was ugly. The example that comes to mind is Pure
Data, which uses the Pd protocol and TCL in the gui connection.
Going this route can reduce a lot of glue code overhead. Printing is
easy, parsing is hard, so let the sender generate something that is
easy to parse on the other side. Often there already is a "default"
I run into this a lot for high level language to bare-bones C on
microcontrollers and real-time core tasks. It seems that often an
application merits its own protocol.
At the C receiving side, it often makes sense to use something simple:
arrays of uint32, or tagged packet C structs. When data gets more
complicated, some nested data structure (e.g. ETF) might be useful.
I've used nested dictionaries encoded in ETF with integer tags.
At the C sending side, generating nested textual data structures is
often just as complex as generating binary ones, making the textual
protocols often more appropriate.