Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Separating input (tty) streams.
Message-ID: <9270@mimsy.UUCP>
Date: Sun, 8-Nov-87 15:03:27 EST
Article-I.D.: mimsy.9270
Posted: Sun Nov  8 15:03:27 1987
Date-Received: Wed, 11-Nov-87 03:07:40 EST
References: <15973@topaz.rutgers.edu> <1987Oct29.152901.2784@utfyzx.uucp> <1757@geac.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 48
Keywords: tty input streams sockets

In article <1757@geac.UUCP> daveb@geac.UUCP writes:
>... I can't for the life of me figure out how to separate material
>written to "/dev/ttyXX" by another user or process from material
>written by my shell or editor process.
>  What I wish to do is leave my /dev/tty writable, but direct
>it to a particular program, while my shell and editor happily use
>the real tty to talk to me, and can talk to the program listening
>for my output.

While this is certainly possible, I think it is solving the problem
from the wrong direction.  It seems to me that opening a /dev file
should be the `least complicated' (whatever that means) way that
exists for talking to some bit of hardware.  Hence opening /dev/ttyXX
(or /dev/ttys/XX) should get you a direct path to that terminal,
as it does even now.

To solve daveb's problem (and my own: I hate interruptions that
splat all over my editor windows too), most programs should not
talk to the terminal directly, but rather through a negotiator.
Whether one talks to this by opening /dev/yyy or by some other
means is irrelevant at the moment:  First we need to determine just
what this negotiator is to do.

What I think I want at this moment is to be able to separate requests
on the basis of the requesting program, with categories `refuse',
`accept', and `conditionally accept'.  The last is a trick:  The
negotiator is to tell me who or what is *behind* the action from
the program.  In particular, `talk' and `write' are invoked by
users, and perhaps I wish not to be interrupted by anyone, but I
will take `emergency' messages.  Conditional acceptance is thus
like having a person screen calls.

When a request is accepted, I want a new window to appear on my
Sun (or whatever).  Since I may be using a remote login facility,
the negotiator must be able to speak across the network.  Using X
or NeWS this is almost trivial, but it might be nice to be able to
do this under SunView or other less capable window systems.  This
may still be almost trivial:  A negotiator can simply talk to
another negotiator, so that the one on the old clunky Vax can talk
to the one on the Sun to have that one open a new window.  And of
course, the negotiator on the Sun can screen negotiator requests
from remote hosts.

Oh well, enough brainstorming for now.  I need to go find some
new kernel bugs I wrote last Friday....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris