Xref: utzoo comp.sys.amiga:17234 comp.sys.amiga.tech:183 Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!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: <8380@agate.BERKELEY.EDU> Date: 6 Apr 88 00:23:10 GMT References: <26736@amdahl.uts.amdahl.com> Sender: usenet@agate.BERKELEY.EDU Reply-To: doug@eris.BERKELEY.EDU (Doug Merritt) Organization: University of California, Berkeley Lines: 64 Keywords: IPC remote protocol FTP, do it right Summary: Counterexample; IPC *is* necessary for a clean design! 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: 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. (Actually this came up in regard to an expert user agent that would handle mail and news on all my various Unix and BBS accounts in a really smart way.) 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). 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. 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: 1) vt100 itself becomes much smarter, because I can still talk to it even when it is nominally "busy" doing a file transfer. With the (old) V2.6 vt100 I use, it's real easy to screw things up due to the lack of this feature. I.e. I tell a remote host kermit to send a file, then I tell vt100 to receive it...oops, accidentally selected "Kermit send"... now vt100 is confused. Another example is the apparent impossibility of telling vt100 to abort a transfer (all it has to do is send "kermit bye"!) You don't *have* to use cooperating tasks to fix these kinds of bugs individually...but I claim it's the only clean way to design-in a fix for *all* of them. 2) The transfer protocol tasks are then available to entirely different layers which don't use the vt100 user interface, which is the kind of bonus that lead to all this interest in designing an IPC interface to start with. 3) Another bonus is that I can now effectively extend vt100 just by writing another task that controls how vt100 works. This is similar to points 1 and 2 but comes up in a different context. A related point: the above applies to any kind of "slow" activity... vt100 should use IPC for sending transfered files to/from the disk, too. In this particular case it's easy to argue that pipes are better; ok, that's still a *form* of IPC to another task. The point is that you want the overseer to remain reactive even when slow I/O is happening, whether from modem, diskette, tape (maybe next year), ray tracing or whatever. 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. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug