Composing data processors or UI elements?

Well, in response to the blog, I was trying to describe a more compositional UI opportunity than just "interleaved lines in the same TTY" which is what you get with the controlling TTY approach of ssh and friends. If each child process was given a distinct psuedo-TTY as its controlling terminal, you could have the parent of the pipeline do interesting things to present separate UI frames from each pipeline element. The shell and terminal combination would be more like a window and display manager framing the widgets displayed by the invoked command(s).

This seemed to me more in line with some of the active UI elements that the blogger was trying to imagine, e.g. you could have an interactive 'ls' output that lets you click to expand/hide aspects of its listing output on the TTY, while sending a traditional machine-readable listing on its stdout for pipeline processing. I could use either or both of these outputs in one command. Having the 'ls' process stick around to drive the interaction makes a lot more sense in the Unix environment than assuming a bunch of pickled objects can stream out of the process and somehow carry their embedded code which can be executed by a different calling context.

One thing that gets lost in all of this fanciful interaction is the question of resource lifetimes. You wouldn't want every previous command process in your shell history to stick around presenting its active UI in your scrollback buffer, just in case you decide to go back and interact further. But you might want to go back a little! I've often wished I could have my 'man | less' pipeline still active for scrolling and search while I was starting to edit the command-line for my next command, based on what I was learning from the manpage.