shf@well.UUCP (Stuart H. Ferguson) (07/15/88)
In order to facilitate discussion of possible IPC systems, here's a suggestion for some requirements that any proposed IPC system should meet. If we can agree on this part of the design, we'll be a lot of the way there. Additions or suggestions welcome. InterProcess Communication Standard (IPC) Overall Requirements: 1. Extendable. The whole point is to integrate the Amiga environment. This means that the communication model must be abstract enough for any specific application to make use of it in a general way. 2. Adaptable. As new programs get written, it must be possible to plug them in directly (no "glue"). This makes it possible for existing programs to be upgraded by just adding a new module. 3. Simple. The design may be as complex as needed internally, but should be only as complex for the programmer as the task he wants to perform. Things should be easiest for client programmers, thus making it simple even for novices to tap the power of existing servers. 4. Safe. The protocol must account for all asynchronicity in the system. Programs using the standard protocol must be able to come and go easily. Application code should not be required to contain Forbid()/Permit()'s. Specific Requirements: A. Where appropriate, it must be possible to have several copies of the same program running simultaniously. It would be a real shame if you can have two editors running but could only talk to one. B. There should be a simple mechanism for setting up communication between a parent task and its subtask(s). Doing it yourself is a royal pain. C. It must be possible to integrate Arexx, Arexx scripts and existing programs with Arexx ports into any new standard protocol. D. Programs need not be loaded in order to receive messages. It should be optionally possible to have programs loaded automatically whenever required and unload when no longer needed. E. There should be some mechanism for providing network support now or in the future. Ideally, networking should be completely transparent so that multiple programs running on a single Amiga could be run on multiple Amigas on a network with no modification. Also ideally, networking should require no special considerations in software so that programs written and tested on a single Amiga will work on networked Amigas. My Humble Opinions: Items 1, 2 and 3, while the most important, are often the hardest to quantify. The "Specific Requirements," while the easist to achieve, are difficult to achieve elegantly. Here's my ratings for some existing and proposed IPC mechanisms (OOIPC is my own favorite, but as you can see, it still needs work). Exec IPC ARexx IPC P/P IPC O-O IPC ----------- ----------- ----------- ----------- 1. sort-of (a) yes (b) sort-of (a) yes 2. yes (a) yes (b) yes (a) yes! 3. no (a) yes (b) no (a) yes 4. no yes? yes yes A. sort-of don't know no no B. no no no no C. -- -- yes yes D. no yes yes yes E. no no probably probably notes: (a) Exec and P/P IPC use the same basic scheme to achieve goals 1, 2 and 3 -- named message ports. P/P IPC just makes them safer by forcing them to exist as long as programs claim to need them. The basic model is the same: You find a port by name, create a reply port, construct a message of the form required by the named server, send the message to the named port and Wait() for the reply on your reply port. I put "no" to requirement 3 since neither makes an attempt to make things easy for client programmers. I put "sort-of" for 1 because I don't consider the "named port" concept to be very abstract or extensible. (b) Using Arexx IPC requires the Arexx program as the unifying facility. The user himself writes scripts to make his collection of Arexx compatable programs work together. Therefore, all Arexx compatable programs are servers, or if they are clients, then they are clients of Arexx, not other Arexx compatable programs. Although this is a reasonable design, it is not a reasonable basis for a Standard, since Arexx is a commercial product. Again, these are my Opinions. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
peter@sugar.UUCP (Peter da Silva) (07/16/88)
In article <6525@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > 3. Simple. The design may be as complex as needed internally, but > should be only as complex for the programmer as the task he wants to > perform. Things should be easiest for client programmers, thus making > it simple even for novices to tap the power of existing servers. The design should be simple for servers, too. One of the reasons there are so many filter programs on UNIX is that it's *easy* to write one: at the lowest level it's just "main() { while(read) { process; write; }}". None of the IPC systems so far satisfy this requirement. Just about any program you write on the Amiga is going to have to handle Exec messages. Making IPC look like Exec messages is actually easier than making it look like something more elegant. Item 0: it should be more efficient than pipes. This is a basic assumption we're all making, but it should be spelled out. After all, named pipes satisfy most if not all of your requirements. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to alt.dev.null. -- "Running OS/2 on a '386 is like pulling your camper with an Indy car"