Xref: utzoo comp.sys.amiga:17375 comp.sys.amiga.tech:203 Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!eos!labrea!agate!eris!doug From: doug@eris (Doug Merritt) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: IPC for Protocols in Terminal Emulators Message-ID: <8457@agate.BERKELEY.EDU> Date: 8 Apr 88 07:18:53 GMT References: <26736@amdahl.uts.amdahl.com> <8380@agate.BERKELEY.EDU> <26928@amdahl.uts.amdahl.com> Sender: usenet@agate.BERKELEY.EDU Reply-To: doug@eris.UUCP (Doug Merritt) Organization: University of California, Berkeley Lines: 91 Keywords: lessons from history, multitasking, pipes, IPC in '88 Summary: Sticking up for IPC (shades of history!) In article <26928@amdahl.uts.amdahl.com> acs@amdahl.uts.amdahl.com (Tony Sumrall) writes: >In article <8380@agate.BERKELEY.EDU> doug@eris.BERKELEY.EDU (Doug Merritt) writes: >> [...] If vt100 lets me tell *it* what to do via IPC, I can >>use it. Otherwise I can't, and have to roll my own. > >OK by me but VT100 is kind of a large "agent". It sounds like you want to >replace the serial.device with VT100. This doesn't sound too good to me >since VT100 is a *terminal* program. [ ... ] it just >sounds like using a pair of pliers to the job of a socket wrench. Although I could use my own wishes as an example, a convenient posting from Randy Groves on the same day serves as an even better counterpoint: :In article <4742@bcsaic.UUCP> randy@bcsaic.UUCP (Randy Groves) writes: :What I need, essentially is something like VT100 with some csh- or rexx- :like language built in or able to interact with the terminal session. :I need to build complex macros to process information on the host to which :I'm attached. The macro languages built into VT100 or other PD packages :I've seen just don't cut it. This demonstrates fairly effectively that, no matter what an author *thinks* his software will be used for, somebody out there will always want some kind of extension made to it that hasn't happened yet. He can either look around for a new package, as Randy requested info about, or do his own hacking to vt100, he can plain do without, OR if vt100 submits itself to IPC control, he can write a simple program to control it, without having to modify vt100's source. Allowing such control is highly desirable due to the impossibility of any piece of software being all things to all users. Or even of foreseeing all reasonable uses. > [...] The "right" way to do this is to write an IPC >serial port server and modify VT100 to use *it*. Then VT100 would >become a true terminal emulator with absolutely no tranfer protocols >within it. Great! I agree, that's *definitely* the right way to go. >> Do you care about whether it's easy >>to use for new applications? Yes? Then use IPC. > >But, Doug, your last few statements sound to me like you asking if I've >stopped beating my wife. Sorry, no offense intended. It may sound that way, but that's because I really do regard this (IPC necessity) as an obvious conclusion. Again no offense, but I feel like arguing in favor of IPC support is like arguing in favor of multitasking. Certainly you have to give it a shot with PC/Mac/Atari/Etc folks, but sometimes they won't really understand until they get hands-on experience. A closer analogy is arguing in favor of pipes; this was something CP/M folks gave me a hard time about when I told them about UNIX pipes. They'd make similar points to yours, about how piping input to their programs was putting the cart before the horse. Sigh. I understand that it seems that way...but how do I explain the functionality gains they'd get if they just TRY being enthusiastic about pipes? (read as "IPC" here). As a matter of fact, it's true that pipes DO fail for some applications. And where they do, IPC message-passing takes over as an even more general paradigm, that gives you the same kind of improvement over pipes, that pipes gave you over, well, over batch-files/interactive-input-required/etc. > [...] I *did* say that I would implement it if and when it became stable >and I was convinced that it was of value to the end-user. [...] Glad to hear it. P.S. When I worked for Molecular some years ago (they made 64-processor z80 systems running a hacked up CP/M), it was difficult to explain the benefits of multitasking to people, because whenever someone needed a new process, they just used message passing to a whole 'nother processor! Which was great; let me tell you though, it was NOT as nicely integrated as the scheme you get from any self-respecting multitasking system. It could have been, but they didn't have experience with multitasking (or pipes) to show them the way. Let's learn from history...anything that increases the modularity of software is a big win (and adding IPC control certainly qualifies, as do pipes, multiprocessors, or multitasking). One last thing...perhaps it sounds like I think you don't believe in IPC, when you do see some benefits from it. Not at all; I just think that you have to apply it consistently as a philosophy. Ideally *any* piece of software should be drivable as easily by IPC as it is from user interaction...this allows each piece of software to become a module instead of a dead end. Look at what's been done with mouse-movement recorders and CLI/shell session savers/repeaters...very handy, but a pity you *have* to do it that way. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug