Pipes and communication

Pipes, streams, coinductive data, continuations – all those are similar and cool. They are also quite natural for communication, since it usually is a continuous process, and it may require some kind of routing, for which things such as pipes are handy.

As wrote before, I think it is nice if participants of a communication can choose the software that works best for them, individually, but varying protocols make it harder. There are bitlbee and XMPP gateways, though those are rather specific.

So, putting those two things together, I've experimented with a common interface for client programs: scf. Having such an interface, one could just pipe one program's output into other program's input to relay messages, for instance, or use it in combination with tools such as tee. It is implemented as a few separate programs in order to emphasize extensibility in any language, which is also important for such systems.

Perhaps the format should be changed to something that isn't JSON, or an utility for conversion should be added: would be nice to easily turn REPLs into IRC bots, for instance.

Although the Plan 9 approach is fancier than pipes, and it has the plumber program – so perhaps that's a better way to achieve those goals. In fact, once I've tried to design a network protocol using something like remotely accessible pipes, mostly reinventing what's already there in 9P. Apparently communication files are getting implemented and mostly lost from time to time.