the medium of unix is ascii. all the world is a sequence of characters. pipes, grep, sed, awk and bash provide a powerful, and largely intuitive environment in which to manipulate simply structured textual information.
what the environment does not handle is concurrency and events and changing situations and priorities. the closest it gets is tee, cron, job control and pushd.
emacs is slightly better at this. it has multiple buffers, the status line, and messages in the mini buffer. it doesn't deal naturally with streams, but buffers which is ironically a tendency towards a more static world than shells.
in some ways the antithesis of unix is the dumb-terminal application. whether curses or 3270-based, it constrains the interactive control of the user to predetermined patterns. although it does provide the possibility of event-driven action, it's not a dominant feature.
X (and smalltalk, plan9, NeWS, and others) extended these basic environments. they allow multiple instances of either or both. the GUI also facilitates better notfication: from biff upwards, the environment can now better react to events, and better concurrency: you can deal with multiple different ongoing interactions.
but individual gui applications tend to reflect the dumb-terminal app. everything from a calculator to a word-processor presents the user with a pre-determined set of actions that can be applied to the object at hand.
the definitive application of the GUI is the multi-media, hyper-browser. the metaphor is no longer a stream, or a buffer, but a tree. the element is no longer the character, but also the bitmap (sound is very poorly integrated, and arguably less useful than a dumb-terminal's beep).
the extension of HTML to javascript-driven active documents effectively makes the browser a virtual terminal, within which typical GUI applications can be executed without needing a software distribution mechanism.
what has been abandoned is the workbench approach of the unix shell, giving the user the ability to create new functionality from existing components. we have gained an ability to interact with hypertext, rather than ascii text. we have yet to get a system that is active, as well as responsive; event-driven as well as user-driven; or truly multi-tasking.
is it possibly to provide a workbench, not unlike a unix shell, within which you can perform tasks not only upon text streams, but upon multi-media objects, and, not only in linear sequential fashion, but also in a concurrent, event-driven way? how can the environment be active as well as responsive?
the first thing to consider is the format of information, and means of processing it. at the basic level, MIME types allow the description of object types. processing the content from there is a matter for individual components. aside from type, is there any other metadata that is useful/necessary?
the second consideration is the structuring of components. bash provides pipes and redirection, forking, and job control. helios' CDL extends these basic operators to include various concurrency contructs, but none are event-driven.
correlator as shell.