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.