Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site oliveb.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry Aguirre)
Newsgroups: net.arch
Subject: Re: Re: dumber terminal device drivers
Message-ID: <394@oliveb.UUCP>
Date: Mon, 6-May-85 21:10:39 EDT
Article-I.D.: oliveb.394
Posted: Mon May  6 21:10:39 1985
Date-Received: Mon, 13-May-85 09:25:30 EDT
References: <327@piggy.UUCP> <2536@nsc.UUCP> <524@hou2d.UUCP> <429@dsd.UUCP> <2023@uvacs.UUCP> <172@ncr-tp.UUCP> <2294@wateng.UUCP>
Organization: Olivetti ATC; Cupertino, Ca
Lines: 45

> If someone attempts a device driver for `dumber terminals' on
> Unix systems, I would suggest that they take a look at how
> Data General has given AOS users a uniform one-line editor.
> 					Terrence W. Holm

The AOS screenread() call is nice and does solve the problem of context
switches.  It also gives a uniform set of editing codes, something Unix
could learn from.  They also have a data-sensitive read in which the
user can specify (via a bit map) the characters that terminate a line.
So even when not doing a screenread the input and echoing of characters
can be done with minimal context switching.  It is really neat to
realize that you can backup on a line, delete some text, insert some
other text, go to the end and add some more, etc. all while your
application is swapped to disk.

AOS needs to save on context switches as it does not do them as
quickly as Unix.  I have compiled programs which did single character
at a time output on both systems and on the AOS system the context
switching really slowed the output even on an unloaded system.  On Unix
the output will slow only when the load is high.

The PROBLEM with AOS screenread is that it only works with a small
number of terminal types.  The terminal type is specified to AOS with
their equivalent of stty.  The drivers for the various terminals are
compiled into the kernal.  Last time I saw an AOS system it only
recognized 4 types of terminals.  Compare this with the number of
terminals types that the vi editor can support (hundreds).

The only answer I can see that provides this efficiency and terminal
independence is to pass some subset of the termcap to the tty driver.
The amount of information and code necessary for INTRA-line editing
is probably not to big.  Where it gets messy is handling line overflow.
The AOS screenread interface is sufficiently complex that it can return
status indicating that the line overflowed while the user was at a
specific column doing insertion.  That is a bit much to extract from
the one word status returned by read(2).  You could add another ioctl to
get that info but doing so adds another context switch.

I think that the setable delimiter table is the best solution.  It
provides most of the efficiency gain and is relatively simple to
implement.  Presumably the delimiter would not echo as the program gets
control and can itself decide whether to echo it.

				Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry