[epistasis]

Oh, I totally agree that the byte stream should be only stream that the kernel itself is concerned with. I'm merely arguing that there's room, in addition to the current situation, for having more highly structured data streams between Unix CLI utilities. I've had great success with piping binary formats for very specialized use, both for IPC and across the network, and I'd like to see additions to the Unix toolset that take advantage of some of those greater capabilities, in a language- and OS-indpendent way.

[jude-]

> I'd like to see additions to the Unix toolset that take advantage of some of those greater capabilities, in a language- and OS-indpendent way.

Don't get me wrong, I won't turn down structured IPC just because it's structured :) However, I have yet to see an IPC system that (1) gives you more than a byte-stream, and (2) allows for universal composability. Every IPC system I have ever come across sacrifices one of these properties to make gains in the other. While I haven't ruled it out, I'm skeptical (but would love to be proven wrong) that there exists a form of IPC that can meet both requirements.

[bitwize]

Dbus.

In the very near future, everything on Linux will be done with dbus.

[jude-]

I sincerely hope you are joking. Dbus-as-IPC doesn't make for composability at all, since each program must be aware of (1) the names and signatures of each other program's dbus-accessible methods, and (2) each other program's behavioral semantics with respect to the method invocation.