Composing data processors or UI elements? [LWN.net]

Composing data processors or UI elements?

Posted May 19, 2011 0:09 UTC (Thu) by Pc5Y9sbv (guest, #41328)
Parent article: Announcing TermKit

The blogger and the comments here on LWN conflate different compositional models: the data-flow composition of standard I/O pipelines; the data-flow composition of processes acting sequentially on the host filesystem; the sequential UI composition of the shell read-eval-print loop; and the parallel UI composition of graphical window managers and their character-cell equivalents.

The blog's second diagram of a process having standard in/out/err and separate view in/out looks exactly like a normal X application to me. You can launch it from a script or command line, and have standard I/O for pipeline composition, but also have the side-channel GUI interface if needed. If there is a problem with this approach for non-GUI processes, it is only because stdout is conventionally overloaded for data stream and textual UI based on the detection of a TTY. A mildly post-Unix environment could easily provide additional standard file descriptors for data in/out, data error out, and operator TTY, allowing for example the use of a process in a data-processing pipeline while also allowing the process to use a terminal-based UI via ncurses or such. A batch pipeline would provide no TTY to the pipelined processes, while an interactive shell could provide psuedo-TTYs to each process and compose them into its own TTY, whether by multiplexing one character-cell terminal or providing multiple emulated terminals in a GUI environment. But, once you start wanting to provide non-textual elements, it is probably better to ditch the TTY-based UI model and just go back to a side-channel to a proper graphical environment.

In either case, you need to address the fact that the data-processing pipeline composition and the UI composition are not necessarily the same topology and actually require a more expressive programming language (e.g. a better shell language) to define both aspects of composition in a reasonable manner. And you would definitely want some standard utilities which could remap a UI channel into a data stream or vice versa, i.e. getting user input and sending it into non-interactive processes at the head of a pipeline, while consuming the output from the tail of the pipeline and putting it back into the UI channel for the user. Or, some combination of this with the native UIs of other pipeline elements.

Completely orthogonal to this issue of separated dataflow and UI is the desire by some to replace Unix's unstructured flows with structure. This can be applied separately to both kinds of channel in a post-Unix environment: object streams replacing byte streams in the dataflow pipeline, or semantic markup models (like Javascript, HTML, CSS, etc) replacing the low-level TTY or X drawing primitives in the UI channel.

to post comments

Composing data processors or UI elements?

Posted May 19, 2011 1:27 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

> A mildly post-Unix environment could easily provide additional standard file descriptors for data in/out, data error out, and operator TTY, allowing for example the use of a process in a data-processing pipeline while also allowing the process to use a terminal-based UI via ncurses or such.

You're actually describing a standard part of classic Unix (though not one of the better known ones!). Opening /dev/tty gives you an fd to the "controlling TTY". This is how e.g. ssh can ask you for your password even when run inside a pipeline.

Composing data processors or UI elements?

Posted May 19, 2011 3:55 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link]

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.