wagner (11/29/82)
Has anyone experimented with using a home computer as a smart terminal rather than just emulating a dumb one? The sorts of things that come to mind are - huffman encoding the data stream at the mainframe, and unencoding at the micro end, to effect a net speedup in data transfer rate (I hate 300 baud) - co-operative text editors, where the screen handling is in the micro, and the data manipulation occurs at both ends; at the micro end for the purposes of the screen image, and at the mainframe end for posterity - local scrolling over a larger history than the screen size (many modern non-dumb terminals do this now) - the ability to negotiate, in a table-driven way, the various signon sequences of a number of different time-sharing services. In my mind, this includes being able to dial in either pulse or tone, being able to wait for dial tones and carriers, reporting intelligently where in the signon sequence the failure occurred if it was unable to complete. - I am sure there are more goodies that one could put into such a package if one thought about it. Has anyone tried to do any/all of these things? How successful were you? Was the concept useful when all was said and done? Would you do it differently next time? Is the code available? Seems this could get lengthly. I will gladly summarize mail that I receive. People who find the summary too concise can get more lengthly transcripts from me via mail. Reply to... Michael Wagner, UTCS (decvax!utzoo!utcsstat!wagner)
Anderson@Cmu-Cs-C@sri-unix (12/01/82)
From: David B Anderson <Anderson@Cmu-Cs-C> I haven't had much luck with mail to UUCP sites, so I hope you get this ... Yes, there has been some work done along these lines. I am aware of 3 implementations, each using various combinations of the ideas you mention. 1. RMS@ai has added local editing (handling simple movement commands and text insertion locally, with burst updates to the host - hopefully this improves the host performance by improving the scheduling of the host editor - you refered to this as co-operative text editing) and line saving (local scrolling) to MIT's version of Emacs. The test implementation involved using Lisp Machines as the local processors, but the protocol is suitable for microprocessors. All of this is described in ai:rms;lep >. 2. Robert Goldberg (Goldberg@Rutgers) implemented a split editor as a part of his thesis at Rutgers. He handled the cooperation in a different way, placing more of the burden upon the local processor, while the host ran a simple line oriented editor. You might contact him for a copy of his thesis, which includes the results of many empirical text editing studies. He reported a speedup by a factor of about 4 (without any data compression - simply from relegating all screen updating to the local processor and remembering all the data sent from the host). 3. Leonard Zubkoff (Zubkoff@Cmu-CS-C) has modified the firmware in our Concept-100s to do some simple data compression and better screen handling. Our versions of Twenex Emacs and Gosling's Unix Emacs support this terminal, and achieve a net speed-up of about 2.5. (75 cps at 300 baud). Details are available in a CMU Tech Report, or online through Leonard. I support some of this protocol in my homebrew Concept emulator for my apple. Additionally, I have been experimenting with other data compression and screen management mechanisms, and am in the process of implementing some new ideas. I'll let you know if they are successful. David Anderson (Anderson at Cmu-CS-C)
BILLW@Sri-Kl@sri-unix (12/01/82)
From: BILLW at Sri-Kl (I can't respond individually, as your return address is longer than 39 character. I think I say enough that everyone will be interested) Yes. Several things such as you describe have been done: - huffman encoding the data stream at the mainframe Someone at MIT has an apple program that does this. I beleive it is in the public domain. I beleive it gets about 30% compression (45cps). Note that huffman encoding really isnt all that wonderfull for the large number of characters that go down a typical terminal line. Zubkoff@CMU-CS-C (? they just changed all their host names) developed software that ran inside an HDS Concept-10x terminal (a z80) that did compression by defining more usefull cursor control comands and by having large fixed and dynamic dictionaries so that common or recently used words could be sent as short (one or two) character sequences. He was able to get compression of some 3 times (480 cps on a 1200 baud line!!!) while editing programs containg a lareg amont of word repitition (MACRO-10 and bliss source code, I beleive). He used all 256 possible 8 bit codes. I beleive HDS droped this, and dont know the current status of the software. I wrote a quick and dirty version of just the dynamic dictionary idea and managed to get about 50% compression running files of "typical emacs output" through it, and about 30% on normal text files. Note that the above approachs require some non-trivial software on the main host translating the output stream of all programs before it is sent out the terminal line. On many systems this is impossible. On others it is slow enough to offset the compression. In almost all cases, it may not be "practical" since the lower connect-time cost could be offset by higher cpu charges. Another slightly better approach is to build the compresion into commonly used programs such as the editor, and ignore other things. - co-operative text editors MIT has defined a "Local Editor Protocol". Other similatr things have been done. I dont know whether any of this has been applied to "popular" editor, or whether a "full featured" editor includes any of these. - the ability to negotiate, in a table-driven way, the various signon sequences of a number of different time-sharing services. Sigh. Without abusing the ARPANet too much, I have written a program (ReCall) for the IBM PC that does this (amoung other things) and will be marketed. It is much smarter than "in some table driven way" in that it allows you to login normally once, and then remembers what you did and how the host responded so that it can do it all again when referred to by name (as in "recall sri-unix"). The idea is extended to allow completely unattended execution of oft repeated tasks (eg, call up dow jones, download the stock prices of x, y, and z, logout, and hangup). Since the program is written entirely in 8088 assembly language and makes extensive use of the IBMs function keys, it isnt likely to be rewritten for other computers (well, maybe the DEC rainbow). It works very nicely, and I like it a lot (you can also use it to do commonly done things in the middle of a session, like downloading a file) - scrolling region bigger than the screen almost all comercially available "smart terminal" programs for micros have this feature. I have never found it to be particurally useful. It is much nicer to have several pages that you can flip back and forth between (and that arent affected by output to other pages). Few programs seem to implement this (The above mentioned concept-100 terminal has a way of faking this feature using its definable function keys and "windowing". I can make available the necesary code if anyone with a concept is interested...) Bill Westfield BillW@SRI-KL ...!sri-unix!billw