Xref: utzoo comp.sys.amiga:17830 comp.sys.amiga.tech:401 Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!amdahl!acs From: acs@amdahl.uts.amdahl.com (Tony Sumrall) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: IPC for Protocols in Terminal Emulators Message-ID: <28845@amdahl.uts.amdahl.com> Date: 19 Apr 88 06:39:10 GMT References: <26736@amdahl.uts.amdahl.com> <8380@agate.BERKELEY.EDU> <26928@amdahl.uts.amdahl.com> <8457@agate.BERKELEY.EDU> Reply-To: acs@amdahl.uts.amdahl.com (Tony Sumrall) Organization: Amdahl Corporation, Sunnyvale CA Lines: 76 Keywords: lessons from history, multitasking, pipes, IPC in '88 In article <8457@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: >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. But I interpreted Randy's request to mean that he wants to interact with the AGENT, not the terminal program. To my mind this means that the he wants to become a "listener" on the serial.device (i.e. both he and VT100 get ALL of the incoming data...both listeners can then respond). He could also talk to VT100, interjecting his own escape sequences or using VT100's resources to display info on the terminal session's windows. >> [...] 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. Lemme see if I've got this right: you agree that VT100 should not be an agent. Rather, it is just an IPC user of the service that that the IPC serial server provides. Great! Now, let's hammer out the services that the IPC server should provide and get down to the nitty-gritty of defining the characteristics of the beast. In particular, please offer some insight on the questions that I asked in a previous posting: 1) How many bytes of data is the owner of the serial port supposed to bundle up into the message that it sends to the external pgm? 2) How does the SP owner (serial port owner) know that the external pgm is finished? or abended? 3) How does the SP owner know when to send the client a TIMEOUT msg? 4) How does the client know the pertinent settings of the serial port (e.g. parity, baud rate, break time, end-of-line chars)? 5) How does the SP owner quiesce the client (in case the user decides to abort the xfer or the user detects a loop or other failure in the client)? Don't try to spend time *convincing* me that IPC is a good thing, spend time defining the IPC interface. Once I see a definitive interface spec that has very few holes I'll be convinced. I'm willing to *work with you* on this! > Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) > or ucbvax!unisoft!certes!doug -- Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]