🚀 go-pugleaf

In article <868@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes:
[ ... ]
>One problem with the "feeding the object" primitive:  how do you specify
>where output should go?  In ViewPoint, destination is hardwired into the
>particular process icon.  For example, an ascii-to-internal converter
>always makes another icon on the desktop, while a printer always sends the
>output to a physical laser printer.  How could one usefully extend the
>"feed to by dropping on top of" metaphor to UNIX-style pipes?

   There was an interesting paper presented at the Summer 1986 Usenix
(the one in Atlanta).  It was entitled, "A Data-Flow Manager for an
Interactive Programming Environment," and was written and presented by
Paul E. Haeberli of Silicon Graphics, Inc.  In this paper and presentation,
the author described a set of simple changes to a window-based environment
that I feel was the best mix of pipes and windows that I've ever seen.
(Not that I've seen all that many, though.)  The idea was that programs
could be written to provide all sorts of inputs and outputs... all of
which had associated with them information as to what input was
expected or what output was provided.

   The window manager provided a visual paradigm by which tools could be
tied together.  There was some mouse function that popped up menus containing
the names of the various inputs and outputs for a given tool, and the
actual connections were displayed as lines/pipes on the screen.  The
pipe information could be hidden so that it wasn't always in the way --
something which I thought was a nice touch.

   Haeberli showed a videotape in which he (or someone else, but I'll
assume it was him) took a tool that provided rotation and translation
information, a tool that provided images, and a tool that displayed
images, and tied these simple tools together to build a tool that
could display an arbitrary image under arbitrary rotations and translations.
The final tool was something that would have been quite time-consuming to
code as a unit, but each tool itself was quite simple.  It was *awesome*.
I was impressed, and I don't think that I was the only one.

   I don't think there was any hard-core typing information associated with
the input and output streams, but I'm not sure.  Even if there wasn't, I'm
not sure that the results of feeding a x-y-z output into an input that was
expecting an image would be any worse than, say, cat'ing a raw disk device
into troff's stdin.  Some special coding within tools is required, but
special coding (admittedly, not a lot of it) is required to use stdin and
stdout, too.  The implementation sounded quite simple, too.  I wouldn't
put it past someone to knock out a simple version using Your Favorite
Window System For Which You Have Source and sockets of some flavor or another
in a couple of months at the outside.  (Of course, there's probably some
subtleties here that I'm missing and that make the problem much harder.)
If anyone does an implementation for SunView, NeWS, or X, I'd love to
take a look...

	-Steve

-- 
Spoken: Steve Miller 	ARPA:	steve@mimsy.umd.edu	Phone: +1-301-454-4251
CSNet:	steve@mimsy.umd.edu 	UUCP:	{seismo,allegra}!mimsy!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742