Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: Hyper Functionality [was Re: An Amiga Conversion Facility (2 of 3) LONG!] Message-ID: <1991Apr22.071413.22219@agate.berkeley.edu> Date: 22 Apr 91 07:14:13 GMT References: <2407@swrinde.nde.swri.edu> <1991Apr18.065847.8050@agate.berkeley.edu> Sender: root@agate.berkeley.edu (Charlie Root) Organization: University of California, Berkeley Lines: 125 In (18 Apr), Mike (My Watch Has Windows) Meyer (mwm@pa.dec.com) writes: > In article <1991Apr18.065847.8050@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes: You SEE? ^^^ vvvv ... I KNEW it would happen... (:-)) > [I'm posting this for Dave Navas, whose news server happens to be down... > -- Pete -- ] Those were DAVE's words -- not mine! Never mind, the response that follows is all my own work..: |> I absolutely positively don't want this thread to die. :) |> |> As far as I am concerned this is the extensibility that ARexx promised, but |> which is really beyond the means for it to deliver. > > I disagree. I think ARexx can deliver this kind of functionality. Oh, Mike,.. Mike... It seems we STILL aren't getting the message across. It's true of COURSE that ARExx is suitable for some Interprocess Communication jobs. Pipes *too* are fine for a lot of such things. Even an EXECUTE script running a sequence of programs that pass their data through intermediate RAM: files is perfectly good enough for a lot of requirements. Each has its area of applicability. But there *are* a lot of things that could be done that ARexx doesn't handle very well if at all. Just take another look at what you've actually used ARexx for: > Examples: I've added a spelling checker and a thesaurus to mg. Someone > wrote the servers (ISpell + it's Rexx port, and the Electric > Thesaurus), and I did the integration. These are all TEXT based things! That's what ARexx is great at. But what about all the other areas we've been talking about -- passing bitmaps and other data structures around, and passing them FAST? > > I can see ADPro doing the bitmap/postscript mappings Kent talked > about. [.....] But how does it pass them to other programs? ...On demand... Without both ends having to parse instruction strings...? Sure, it could write a file for another program to pick up, but I thought that was what the proposers were trying to avoid. Then there are all the other "Hyper Functional" opportunities. How would you pass MIDI events around at ARexx speeds? How would you use ARexx to build data acquisition, filtering, and processing "plug-in" modules that pass structured data around at high speed (as Kent has been doing with ppIPC)? (Actually MIDI is probabaly not a good example; it is specialized enough, and demanding enough, an application to deserve a system tailored to its own needs -- a function that Bill Barton's midi.library looks, at a very brief glance, to fill admirably. However, for communicating outside that domain -- say for a MIDI trigger to an image display animation -- you again want something more general, such as ppIPC.) It might clarify things a bit if I briefly describe how the IPCMessage format works in the context of the particular project I'm finishing up at the moment. One of the things this does is send (text) commands to other processes, which often receive them simply by opening an "IP:" device pipe. [Yes -- this is mostly a text based application here too, but other things are involved, as you'll see.] The normal ID of such a message is `CMND', which is one of the types that the IP-device recognizes. The only item in such a message is of type `LINE', which again the IP-device knows how to handle. When requested to do so, the program will output a more detailed message for recording purposes, indicating, as well as the command text itself, the channel (port) that the command is normally sent to. This is given the ID `DATA', and contains a `PORT' item before the `LINE'. If you want to receive this with an IP channel, you can do so (though normally it goes to a specialized program); the IP device recognizes the `DATA' ID, so reads the `LINE' properly, but simply ignores the `PORT'. (If you're doing it this way, this is presumably what you want...) You don't get ALL the information available in the message, but at least nothing breaks. In the other direction, the program has a single control port which can accept several kinds of messages, and passes them on to the appropriate handling routine with a brief switch/case sequence. (No command line parsing here!) One of the types is of course `DATA' -- of the same format as the ones it can send -- so that it can be restored to (selected parts of) a previous state. Another message type is `DUMP', which specifies a destination and causes it to spit out the `DATA' messages we were just talking about. Another message is `CNFG': this one configures the program in a number of ways, and is very flexible in format. Each possible configuration parameter has a corresponding item type (`WPOS' for window position is just one example) each of which may be present or absent as need dictates, and they may be in any order. Again, "parsing" is trivial -- just a loop that goes through the items in sequence, taking action via a switch statement. The parameters passed of course are already in the correct form -- mostly (short) integer for the configuration parameters. Any translation required from, say, keyboard input is done by the transient program that sends the message. You see the difference from ARexx, where the only way to distinguish message functions is by the command string itself, which needs parsing at the destination, and maybe other massaging as well. ppIPC message recipients can usually be very simple, and composing a message to send is not very complex either. Both are very fast. Command parsing only has to be done in one place -- often in a program that only runs long enough to do its job. Typically the server program doesn't need much text handling ability itself -- maybe not even text output, or at least only the most basic `puts' kind. The other side of the coin is that there is no particular user-level command language associated with ppIPC. Things are done via C-level (or any other compiled language for that matter) calls. There's no reason, though, not to use ARexx to manage the ppIPC connected processes, if that is appropriate and you can afford the speed penalty. Although ARexx can't generate IPCMessages, it can write or read an `IP:' channel just as well as any other program that can open a file. A net of ppIPC processes has to be commanded somewhere by the user -- most likely by a text string -- and ARexx can happily supply this. For ARexx control in other parts of the net, you could easily plug in the necessary links if you had to. Ah well -- another posting that's about twice as long as I'd hoped, but maybe it's made our rationale a little clearer. I'm not trying particularly to put down ARexx: there are a number of places in my usual environment where it's indispensable these days. However, there *are* multitasking applications that one can't do with ARexx, but can with something like ppIPC. All I want -- as Dave does -- is for people to expand their horizons from the linear old-style straightjacket. Think about it, folks. -- Pete --