Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site hammer.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!orca!hammer!steveg
From: steveg@hammer.UUCP (Steve Glaser)
Newsgroups: net.arch
Subject: Re: dumber terminal device drivers
Message-ID: <1170@hammer.UUCP>
Date: Mon, 15-Apr-85 04:06:14 EST
Article-I.D.: hammer.1170
Posted: Mon Apr 15 04:06:14 1985
Date-Received: Thu, 18-Apr-85 02:47:31 EST
References: <327@piggy.UUCP> <2536@nsc.UUCP> <524@hou2d.UUCP> <429@dsd.UUCP> <2023@uvacs.UUCP>
Reply-To: steveg@hammer.UUCP (Steve Glaser)
Organization: Tektronix, Wilsonville OR
Lines: 42
Summary: 

In article <2023@uvacs.UUCP> mac@uvacs.UUCP (Alex Colvin) writes:
>Providing a bit mask for terminating characters isn't enough.  For
>instance, it's usually the character AFTER an ESC that's the terminating
>character.  The ESC[ ... control sequences can be arbitrarily long, and
>appear to terminate on an alphabetic character.
>
>It's a mess.

Alternatively you could just make the terminal driver echo only between
write requests (provided the request was under some specified size -
writes of over that size would work, but might have echoed characters
in them).  The only change that this requires is that applications be
careful when they flush the output buffer if they care about echoed
characters.  I don't think delaying the echo until the end of a write
would be noticed by most users - if the machine is really typing at
you, you aren't going to be able to read what you're getting echoed
anyway - even if the machine is only typing text.

As for terminating characters, something like the following looks.  If
there is a pause of over ___ time between characters, consider it a
terminating character.  If less than that, keep looking (it might be a
multi-character keystroke).  Granted, it has problems over networks and
fancy terminal switches where timing gets mangled, but then unix has
always had problems in that arena (e.g. output delays get lost also).

The only real long term solution is to go toward something like the
Virtual Protocol Machine (VPM) from System V.  I think there is a
version for async lines (doesn't the 5620 DMD support uses this on the
3B computers?).  Granted, it's probably overkill and it's definately
not very portable (not everybody implements VPM), but it does provide
the right kind of hooks for dealing with this sort of problem (you get
full user programmability as interrupt level cause it's in a dedicated
processor).

Don't hold you breath waiting for anything like this though.  Outside of
AT&T offerings, I don't know of any VPM implementations.  Maybe AT&T will
do something like this as a stream processing module in System V Release N
(for some appropriately large value of N).


	Steve Glaser
	Tektronix Inc.