Path: utzoo!mnetor!uunet!husc6!m2c!ulowell!hawes From: hawes@dino.ulowell.edu (Bill Hawes) Newsgroups: comp.sys.amiga Subject: Re: IPC (1): Ports & Messages Message-ID: <1948@dino.ulowell.edu> Date: 11 Mar 88 03:33:24 GMT References: <7412@agate.BERKELEY.EDU> <752@nuchat.UUCP> Reply-To: hawes@dino.ulowell.edu (Bill Hawes) Organization: University of Lowell Productivity Center, Lowell MA. Lines: 126 Keywords: InterProgram Communication, tools Newsgroups: comp.sys.amiga Subject: Re: IPC (1): Ports & Messages Summary: Expires: References: <7412@agate.BERKELEY.EDU> <752@nuchat.UUCP> Sender: Reply-To: hawes@dino.ulowell.edu (Bill Hawes) Followup-To: Distribution: Organization: University of Lowell Productivity Center, Lowell MA. Keywords: InterProgram Communication, tools Newsgroups: comp.sys.amiga Subject: Re: IPC (1): Ports & Messages Summary: Expires: References: <7412@agate.BERKELEY.EDU> <752@nuchat.UUCP> Sender: Reply-To: hawes@dino.ulowell.edu (Bill Hawes) Followup-To: Distribution: Organization: University of Lowell Productivity Center, Lowell MA. Keywords: InterProgram Communication, tools ----- News saved at 11 Mar 88 03:26:04 GMT I've had a chance to read and digest some of the ongoing IPC thread and have a number of comments and suggestions to add. First an introduction: I'm Bill Hawes, perpetrator of ARexx (and ConMan, and WShell, and ...) have a number of comments and suggestions to add. First an introduction: Since ARexx was my first Amy project (begun in November, 1985), I've had much time and occasion to examine the IPC issue. ARexx was intended to define a "macro language standard" and was implemented with the intention that a wide variety of software could use it for macro processing (or macro expansion, as Matt called it). First, a couple of comments about the (REXX) language. In this forum REXX already has three strikes against it, since it is *Not C*, but then it was never intended as a medium-level development language. REXX was designed to be accessible to novice (or even first-time) programmers, but is powerful enough to catch the interest of the expert as well. How many languages allow you to pass programs as arguments to functions? Include source-level debugging as part of the language definition? Provide a "content-addressable" symbol table? REXX has a a lot of good features, even if it does DO; ... END instead of { ... } But whether or not you like the language, the IPC protocol used by ARexx stands by itself; there's nothing to say that an application with an ARexx interface couldn't receive commands from a C program. It would probably even make things run faster :-) The IPC protocol implemented in ARexx uses public message ports to identify the applications (hosts) that can receive and send messages. ARexx specifies the structure and content of the messages it sends and expects to receive (obviously), but there is plenty of room for extensions to this part of the standard. The REXX messages are structured like this: struct RexxMsg { struct Message rm_Node; /* EXEC message structure */ APTR rm_TaskBlock; /* pointer to global structure */ APTR rm_LibBase; /* library base */ LONG rm_Action; /* command (action) code */ LONG rm_Result1; /* primary result (return code) */ LONG rm_Result2; /* secondary result */ STRPTR rm_Args[16]; /* argument block (ARG0-ARG15) */ struct MsgPort *rm_PassPort; /* forwarding port */ STRPTR rm_CommAddr; /* host address (port name) */ STRPTR rm_FileExt; /* file extension */ LONG rm_Stdin; /* input stream (filehandle) */ LONG rm_Stdout; /* output stream (filehandle) */ LONG rm_avail; /* future expansion */ }; /* size: 128 bytes */ ARexx marks its messages with the string "REXX" in the ln_Name field of the message, so you can easily tell whether it comes from a REXX macro. The two result fields are used to pass either integer codes or return strings, depending in the options requested. The command or function name and arguments are held in the rm_Args[] array, which looks just like the argv[] array passed to a C program. The commands or arguments are passed as null-terminated strings, but with the length available at negative offsets if you're passing arbitrary data. The rm_Action field is an integer code that specifies an action (e.g. "command") and any options. It is quite true that ARexx does not set forth a "complete" IPC standard. ARexx does not define a standard command set that host applications should support, and it does not define a higher-level "name broker" to track which applications are available or what kind of IPC protocol they support. The issue of standardized commands is important, but imagine the howls of outrage had I attempted to dictate what commands an editor, a database, and a paint program should support! The command set should be decided by the program's developer, ideally in conjunction with other developers of related (re: competing) products. ARexx itself can issue any sort of command; if your program wants to receive a four-byte integer followed by a bitmap, ARexx could oblige (though it might look ugly from the macro programmer's perspective.) The higher-level components of the IPC standard should be fairly easy to design and build. It would be quite straightforward to build the "name broker", and I'd be glad to help in designing such a beast. I'm planning to build a network demon to support remote-procedure calls in REXX anyway, and it would offload much of that work if I could assume that a name broker existed on the other machine. I think most of what Matt Dillon outlined in his SARC proposal fits well within what ARexx already does, once augmented with a global name server. For example, to allow a host to "go away" before a macro had finished processing, you need only have the name broker manage the replyport for your invocation message. When your application closes down, the macro program(s) will break cleanly and eventually reply the original message. Anyway, I'd like those of you interested in IPC standards to at least consider supporting the ARexx protocol. For my part, I will create a public-domain extract from my header files giving the data structures, definitions, and conventions used by ARexx, and propose that as the medium-level IPC standard. We can then work on defining higher-level components and on standardizing the command set. -- Bill Hawes "I have no employer, but if I did, they would share these opinions."