Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Time is of the essence on IPC. Message-ID: <872@nuchat.UUCP> Date: 30 Mar 88 01:44:45 GMT References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <25552@amdahl.uts.amdahl.com> Organization: Public Access - Houston, Tx Lines: 77 In article ... kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > Now wait a minute. ARexx is, first of all, an interpretive language processor, Bingo. AREXX is a script program that happens to include an IPC facility. > As a simple example of this, one of the fellows here (Bob), has AmiCron fire > off an ARexx script when he wants to wake up. The script executes the "date" > command, and parses it up and feeds it to the "say" command. Voila! Amy is > an alarm clock. (BTW, the parsing is fairly extensive, so the thing will say > "o'clock", and "twenty" rather than "two" "zero", etc.) I can already do this with pipes, etc... run date >pipe:datepipe run bawk ... pipe:bawkpipe say Sure, you could write a dedicated program to do that, but doing it this way > takes advantage of existing system commands and resources, and you get some- > thing that works in a couple of hours, rather than in days. Just like writing UNIX shell scripts. Wow. Maybe if I had a UNIX-like shell that I could use for this... :->. > Third, ARexx is set up to talk to *any* program that wants to talk to it. And > it does this via "plain message ports". Sure, the *format* of the messages > is specialized, but that is true for all messages, to some extent. This makes > ARexx an almost ideal macro processor for any application to use. No longer > does a developer need to implement their own special macro facility, they can > just add in some *simple* interface code (about 1.5K for the "dme" interface) > and they have instant macros. And they get the processing power that the REXX > language provides, just like in the system interface application above. But all programs already know how to talk to pipes. The interface is already there. And you don't have to stick with a weird PL/1-like language. You have your choice of any number of weird C-like languages. > Fourth, because ARexx is truly multitasking, and can handle an arbitrary number > of "hosts" simultaneously, it can be used as the "hub" for application-to- > application IPC... Just like pipes. And they already have the "PIPE ports". > Fifth, the functions in those shared libraries can be made available to any > application that wants to make use of them via the ARexx facility. Just like pipes, except they already have the "PIPE ports". > I really fail to see how "clipboards, devices, and pipes" can provide these > kinds of capabilities in a uniform and essentially transparent way (to the > application, that is). As for "plain message ports", as I mentioned earlier, > that's what ARexx *does* use. AREXX uses plain message ports with an intermediary (can you say performance problems? I knew you could!). > And ARexx is shipping now, and it works. For about $50. And it eat's up all > of about 34K. And there are free PIPE:s, with source even. I asked "what about an AREXX:", and was met with silence. > So Ron, it's there now. It may not be the "best" way of doing IPC, nor > "object oriented", or whatever, but it just might let you get on with the > job of developing those nifty applications. Today. The name's "Peter". -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.