Xref: utzoo comp.sys.amiga:17311 comp.sys.amiga.tech:194 Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!oliveb!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: <26928@amdahl.uts.amdahl.com> Date: 7 Apr 88 06:02:35 GMT References: <26736@amdahl.uts.amdahl.com> <8380@agate.BERKELEY.EDU> Reply-To: acs@amdahl.uts.amdahl.com (Tony Sumrall) Organization: Amdahl Corporation, Sunnyvale CA Lines: 89 Keywords: IPC remote protocol FTP, do it right In article <8380@agate.BERKELEY.EDU> doug@eris.BERKELEY.EDU (Doug Merritt) writes: >In article <26736@amdahl.uts.amdahl.com> acs@amdahl.uts.amdahl.com (Tony Sumrall) writes: >> [...] I'm implementing external xfer pgms >>in VT100 R2.9 *now* and am *not* doing anything near what's proposed. What >>I *am* doing is allowing the user to specify the complete command that is >>to be used to invoke the external program (complete with replaceable host >>and local file names). The reasons that I'm not doing IPC are pretty >>simple: Whoa, hold on a sec, Doug...you left out my reasons! In particular, you left out the last on the list (but probably the biggest single reason): the interface isn't designed yet! How can I implement an IPC method if I don't know what to implement? 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. I stand by this. Now, on to your reasons that I should do it. >I have a very simple counterpoint. I want to write higher-level layers >on top of the transport protocol (if that's the right term). I want >to do a fancy user interface that does lots of stuff (let's say somewhat >like 'dnet', for purposes of discussion), including supporting some file >transfer methods. 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. Yeah, once IPC becomes stable and I implement it and the standard includes all of the stuff you want to do I don't see why you couldn't use it as your agent but, well, it just sounds like using a pair of pliers to the job of a socket wrench. >You are taking the exact opposite tact, of calling some external program >which will do the transport layer stuff for you. Fine, for adding >new and obscure protocols. Probably a good idea. But certainly has >nothing to do with the issue of letting some other process do the >same with *you* (vt100, that is). Well, if you call ZMODEM and CIS-B obscure protocols then I agree. >In short, if you don't have something very similar to an IPC method, >then the features being supported in vt100 have to be reinvented if >we want another layer on top of it. Sounds to me like VT100 should become a layer on top of a general IPC facilitator for the serial.device--VT100 wasn't designed to be an interface to the serial port for other programs. I'd be more than happy to replace the serial port interface code in VT100 with IPC interface code to talk to the IPC serial port server! >As a matter of fact, the "right" way to do this is to go ahead and >implement *all* of vt100's transfer protocols as separate tasks that >vt100 communicates with via IPC, for the following reasons: I didn't include your reasons mainly because I think you're headed in the wrong direction. 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. Of course the proposed IPC standard for the serial port would have to be expanded to include a "listener" request (all data coming in the serial port is given to this client as well as any other clients) in order to provide for an ASCII capture. Once this is implemented you can have whatever terminal emulator you like. They become easier to write (no transfer protocols to worry about), smaller (for the same reason), and you (the end user) only have to keep the pieces that you need (don't use kermit? fine, don't bother keeping the IPC kermit program). Anyway, like I said in my original posting, I *will* implement IPC if/when it becomes stable and I can see a tangible benefit to the end user. I believe that 2.9 will be out before the IPC becomes a standard (if I could implement a standard that doesn't exist yet I'd be *much* higher paid than I am now :-). >So it seems to me that the only question is whether you care about >how flexible your software is. 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. "Do you care about whether it's easy to use for new applications?" Yes, I do. "Then use IPC." How does this follow? > > 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. ]