Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!amdahl!kim
From: kim@amdahl.uts.amdahl.com (Kim DeVaughn)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <25552@amdahl.uts.amdahl.com>
Date: 26 Mar 88 03:52:18 GMT
References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <853@nuchat.UUCP>
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 101
Summary: "the time has come", the walrus said, "to talk of many things" ...

In article <853@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes:
> In article <1661@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes:
> > The amiga
> > is to the point where we should not continue arguing about fundamentals,
> > which a good working IPC is.
>
> Gee, I brought this up back when AREXX came out: pointing out that the
> existing mechanisms for IPC (clipboards, devices, pipes, and plain message
> ports) were quite adequate. For the sort of thing you can use REXX for, I
> still can't see that they need work.

Now wait a minute.  ARexx is, first of all, an interpretive language processor,
that just happens to understand the REXX language.  Which means you can write
standalone programs (like a calculator, or a grep-like thingie, etc.), and it
will dutifully execute them for you, just like any other language processor.

It's I/O *is* restricted to command-line-like input, and console-like output,
or files (i.e., no builtin window support, etc), which is one of the things
that keeps it small.  You can, of course, develop your own shared libraries
of any functions you want, as it's also extensible (via the library route).
So if you want it to be able to "speak" windows, gadgets, etc., that *can*
be done.  Might require a bit of work however ... :-)


Second, ARexx just happens to know how to talk to "The System".  That means
it is ideal as a script processor.  And you can use it's internal processing
capability (i.e., the REXX language) to control the script's flow, and/or
process data that may be generated as a result of invoking system commands.

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.)

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.


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.


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.  And the internal processing power of ARexx can perform data
manipulations, format conversions, etc. inbetween them.  So, for example, *if*
Sculpt-3D and VideoScape3D both had the facilities in them to talk to ARexx
(and had the necessary internal commands, naturally), they *could* exchange
data, with neither of them being any the wiser about who "the other guy" was.

Individually, they only need to talk to ARexx.  Depending on the complexity,
and quantity of data to be exchanged, one could have ARexx perform such data
conversions, or use some user written (third party supplied ?) shared library
functions, or even invoke yet a third standalone application to perform the
processing.


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.  Can you
say, extensible applications?  This can be a very powerful concept.  Want a
spelling checker inside your paint program?  It may not make sense, but you
could do it.  All you need in the paint program is an ARexx interface, a way
of "escaping" to an external command, and a means of specifying the data you
want checked.  Externally, you need ARexx, a shared library, and the dictionary
(which could all be used by your word processor, spread sheet, and pagesetter).
Oh yes, the "paint program" also needs to be able to detect and process the
return codes ARexx sends back, so it can signal you when you make an error.


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.

And ARexx is shipping now, and it works.  For about $50.  And it eat's up all
of about 34K.

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.

Standard disclaimer:  I have no interest in ARexx, other than as a satisfied
user of the product, etc.

/kim


-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25