...I'm working on a prospective new product (details to follow, when it's approaching release) involving a Raspberry Pi as, among other things, a sensor platform.
The nature of the sensors (as connected to a RasPi) is such that they need to be polled in real time, fast, which sort of calls for a daemon decoupled from the application program. (Connected to an MCU running AGROS, with a little more choice of connected signals, it could be less demanding, but the RasPi is the platform at hand, and rapid polling at a predictable interval appears necessary.)
So, how for the app and daemon to talk to each other? Shared memory? UDP, perchance? Or - happy thought - see how gpsd does it?
How gpsd does it turns out to be JSON-over-stream, where the stream is canonically a TCP socket. Which is rather complicated, but vastly flexible.
Hmmm.
Well... since this is meant to be open source anyway... and it will likely coexist with gpsd... maybe I just borrow some big chunks of code from gpsd.
Or, if I wanted to be truly obnoxious, I could make it look like a programmable instrument speaking SCPI.
Dither, dither. I'm sort of leaning toward binary packets broadcast via UDP, which is more compatible with the overall notional system architecture. Still... borrowing the framework from gpsd has a certain elegance to it, and it's not like efficiency in the internal communication layers is all that crucial.
Update: on further consideration, binary is not so good: the client won't always be in C, and most other languages these days are not at all friendly to specified binary record layouts. So, some sort of text format over a stream, either JSON or XML.
Comments