Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: Re: Filtering Everything Message-ID: <6943@brl-adm.ARPA> Date: Fri, 17-Apr-87 00:27:36 EST Article-I.D.: brl-adm.6943 Posted: Fri Apr 17 00:27:36 1987 Date-Received: Sun, 19-Apr-87 10:11:56 EST Sender: news@brl-adm.ARPA Lines: 31 ? What do you mean, the program would have to live in my terminal? Just what I said. ? If you ? mean that my terminal would have to know about the data compression, then ? that is no problem. I am not using a terminal; I am using a terminal ? emulator which my company (S. M. Vorkoetter Software) markets, and to which ? I obviously have the source code. My mistake, I didn't really think about emulators as terminals. ? My idea is to compress data going from ? the host, and uncompress it when it reaches the emulator, a process that is ? completely transparent to the user of the system. Except that in order to compress data, you need to collect statistics on frequency use. So you need to synchronize the xmt'er and rcv'er tables, unless you periodically transmit them. Also, suppose you *can* compress the data, say, four input bytes down to three. What do you do when the third character is a line feed, or if you are using character I/O for input? You lose your advantage, and you force some means of deciding whether to buffer and encode or send it now, because the data is needed. It's *NOT* hopeless, but it's not trivial either. Telnet protocol provides `macros' as well as other features. Other protocols provide abbreviations for repeated characters. Have fun in any case. (Root Boy) Jim "Just Say Yes" Cottrell I want to kill everyone here with a cute colorful Hydrogen Bomb!!