On Sat, Aug 07, 2021 at 06:59:08AM -0600, Lincoln Auster wrote: > Hi, > > > Anyway, you're correct, and that's why modularity (which needs a > > better interchange format than UNIX's stream of bytes, to be honest) > > This is pretty irrelevant to the original email, but in terms of IPC > protocols, what would you suggest instead? > My problem is that a lot of tools output and/or take tabular data (lists being a special case with 1 column); with newlines being a massive pain in file lists or ls/df/free/etc... output being a pain to parse _properly_. What I would propose: * Environment variables FS and RS can be used to define the field and record separators; these would default to ASCII US and RS (which is, after all, the reason these control chars exist). * All tools should have options to override them (even if you can already override the env by invocation). * Either make control characters forbidden in filenames - POSIX will never do that, as the austin group bug tracker shows - or use US and \0 as default values for FS and RS.
> I've been writing a small application with dbus recently, and I've been > pretty happy with dbus as a protocol. It looks to be very good at > solving some of the problems that plain text can't, and its interfaces > seem like not at all a bad a choice for complex (that is, non purely > textual) interaction. I imagine, however, that its OO-ness and relative > size make it somewhat unpopular among the 'minimal-at-any-cost' subset > of the suckless community. Does anyone have any specific protocol > recommendations, and thoughts on dbus (or RPC in general) as a method > for complex IPC? thanks! > Personally, I think the concept is nice, even though https://9fans.github.io/plan9port/man/man4/plumber.html was a better solution. I'm quite partial to UNIX domain sockets and IPC FIFOs (with a dummy writer fd opened by the receiver), but it's obviously less "streamlined" than system buses.
