Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <48285@sun.uucp>
Date: 5 Apr 88 17:52:25 GMT
References: <1571@louie.udel.EDU> <353@brambo.UUCP> <1661@louie.udel.EDU> <595@imagine.PAWL.RPI.EDU> <885@nuchat.UUCP>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 68

In article <885@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes:
>*I* don't care about stdin.

Good for you.

>In dPaint: select Save, and specify "PIPE:butcher". In butcher: select Load,
>and specify "PIPE:butcher". The programs talk to each other, pause when the
>PIPE: is full, and so on. Voila. IPC.

Try this too, make an execute file that has (not sure of the syntax here)
.label:
  execute pipe:execute_me
  loop label

execute that in a separate window, then in your favorite editor that has
multiple buffers, use Save As pipe:execute_me as a command to execute the
current buffer. 

>> 	If you don't like the Rexx language, write your own program that uses
>> ARexx ports to control other programs in place of ARexx itself.
>
> Good idea. Something like this should be freely available to ship with
> everyone who wants to use REXX ports but doesn't want all their customers
> to have to buy REXX. This would solve my biggest complaint with REXX: you
> can't distribute it.

I've read most of the IPC stuff and this seems to be only identifiable
problem with aREXX, basically, it isn't free. This is also why IPC will
take *YEARS* to standardize, you see if a requirement is that the handler
be free, then only people who are working in their spare time will write
it, and if they are working in their spare time, they are usually not open
to writing it the way *you* (the editorial 'you') want it written. Rather,
they will write it they way they want it, it is their time after all. 

>It [aREXX]  takes extra context switches:
	[stuff about how aREXX might work deleted]

>If you don't have an intermediary:
>	Program sends message.
>	Context switch.
>	Receiver gets message.
	[more stuff edited out, this is the key anyway]

In the above model, the the program sending the message either (uses the
existing Message port facility (so there is no problem)) or be has all of
the reliable message passing stuff built into it adding bulk to every 
program using IPC or it this not what you are suggesting? Even with the
PIPE: example above you have to switch context into the pipe-handler.

[Paraphrased : "What do you want out of aREXX?"]
>SO THAT PROGRAMS THAT DON'T KNOW FROM AREXX CAN USE IT.

Sorry Peter, there is simply no way that this will work. Programs *must*
know about IPC to use it, in the case of the PIPE: device the programs
already know about filesystem semantics and the pipe: device implements
them, so programs that know about how to use the filesystem can use
PIPE:. But what is painfully clear is that the filesystem semantics are
insufficient for all of the things that people want to do.

Think about the architecture of how programs communicate, or don't 
communicate. When filesystem semantics are sufficient, use pipes, when
they aren't you need something more powerful. I think aREXX is a good
stab at that more powerful facility. 


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.