Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!oliveb!amiga!mitsumi!jimm From: jimm@mitsumi.UUCP (Jim Mackraz) Newsgroups: comp.sys.amiga Subject: AREXX and ICP Message-ID: <267@mitsumi.UUCP> Date: Fri, 11-Sep-87 14:22:20 EDT Article-I.D.: mitsumi.267 Posted: Fri Sep 11 14:22:20 1987 Date-Received: Sat, 12-Sep-87 22:26:03 EDT Reply-To: jimm@mitsumi.UUCP (James Mackraz) Organization: Mitsumi Technology Inc Lines: 127 Now that our newsfeed is working, I am reposting these comments on Inter Process Communication and AREXX on the Amiga. They are a little old. -------------------------------------------------------------- Since I haven't sounded too supportive of WHawes AREXX project, I should clarify. For background to those even less knowledgable than I, AREXX is a powerful interpreted (i think) language which reminds many people in purpose of the C-shell script language, but is reported to be much more powerful. The language program has the capability to send messages to applications, which if matched with applications which understand the messages, can give flexible "macro" capability. To understand the context and reason for my remarks, it is probably necessary to have been at the relevant BADGE meeting. Part of my villian role comes from my missing a portion of that meeting. My comments, nevertheless, follow. I like the language part of REXX. I think it does/will make a fine product. I have problems with two things: 1) the unnecessary and (my view) unhealthy assumption that interprocess messages are somehow tied in to the rexx effort, and 2) the specifics proposed for the protocol of these messages. For shorthand, refer to inter-process messages which have some application meaning as IPC (inter process communication). On the first point, IPC is something that the amiga lacks, and surely needs. A standard for receiving--and sending--messages and a library or device (or "server") to support this would be a great contribution. There is no reason, however, to think of AREXX as the only program to be sending such messages. For example, if a 3-d object editor saves a videoscape 3d file to ram: and sends a message to videoscape to render it, there is no rexx in the picture. As another example, I would like a PD (i.e., free) message sender/macro language , instead of REXX, to be available. Perhaps with a graphical interface instead of a more traditional language. (Recall HyperCard.) Another example: if a spreadsheet program is asked to dump a section of the spreadsheet to the clipboard, (perhaps for use by a separate graphics program), when that section is later changed, perhaps a message of some broadcast type (or routed to the last user of clipboard data?) could be sent out as notification. The graphics program could acquire the new data and be well on the way to processing the new version of the previous graph in the background, and even be done before the moment that the user asks to see a graph of his new figures. Again, no macro language here, just communication between programs, tuned to the concept of data interchange. On the second point, my problems are with the description of the message protocol Bill was proposing at BADGE. First, there is no "common command set" of messages, such as "create a window," "create a new 'thing,'" "delete a thing," "refresh a thing," "save a thing," or "send me a thing." The reference article for the meeting was Bill Gates' contribution on "dynamic data exchange" in the BYTE supplement. DDE has a common command set that would be a start. The absence of a common command set and some standard examples is one reason the Amiga clipboard is a practical failure. The protocol proposal "can transmit anything, it's completely open," but remember the clipboard can "store anything," as well. An extensible command set is better than a command set reinvented for each application. Compare the now standard contents of the "Project" menu. Secondly, the plan was to send IPC messages to a task's IntuiMessage port. 1) This is not a public port. Intuition does some weird things with its messages, and probably needs some work in that area. 2) It is better, from a flow of control point of view, and very easy, to service two ports. The IPC port should be named subject to some clever conventions, and installed on a system list for public access. Don't mess with Intuition's problems. I didn't follow the implementation plans regarding a "Rexx Message Server," but I heard more about REXX than about servers in general. For instance, suppose REXX (or my program) sends a message to a program that is in the process of closing down. What then? The program may well have completed clearing its window idcmp port, so any IPC message at that port is about to get deallocated. A protocol for removing public ports from access before closing must be sure that messages do not get sent into space, and that they are always replied. It was proposed that inter-process data exchange would be accomplished with these messages, supplanting or in addition to clipboard support. This is very probably unecessary--the clipboard should suffice--and if unecessary, a very bad idea. There was discussion about REXX loading a program if a message was to be sent to it. I didn't hear enough to know how a program would be unloaded. What if, in pseudocode: DO 5 TIMES send message to dpaint ENDDO. Does this load dpaint 5 times? The worst thing I heard was that the execution environment of programs loaded by REXX would be yet different from both the CLI and the Workbench environments. Just what the world needs, another condition in application start-up code. The WB environment was described as inadequate, without justification. (Slurs against the CLI environment need no further justification.) On this, I know we would all like to rewrite the AmigaOS from scratch, but the same reasons we couldn't do it at Commodore-Amiga apply in this case. And if those reasons need to be re-learned, let's not learn them at the expense of the IPC potential of the Amiga OS. This potential is truly great. The excitement over this aspect of AREXX is well founded, but a little misplaced. The knowledge, talent, and efforts of the people working with AREXX are indeed critical to the success of a standard for Amiga IPC. My claims are that this effort should not be tied to REXX, and that it should be more sensitive to the existing and future pieces of the system and the standard problems of IPC such as those I have indicated above. I welcome corrections and comments, and general discussion and proposals for general IPC. If someone can summarize Microsoft's DDE, it might be food for thought. jimm {amiga!pyramid}!mitsumi!jimm -- Jim Mackraz Mitsumi Technology, Inc. {amiga,pyramid}!mitsumi!jimm