Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <5377@well.UUCP>
Date: 5 Mar 88 22:57:56 GMT
References: <5375@well.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: The Society to Turn Wesley Crusher into a Styrofoam Dodecahedron
Lines: 85
Summary: Here we go....

In article <5375@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
>
>IPC - Standards
>
>A proposal
>
>Yeah, let's do it!  It's high time that the Amiga had a standard method of
>inter-process communication.  With products like ARexx and Browser coming
>out, we may get stuck with a "de-facto" standard which may not be well
>designed, or several "standards" that are mutually incompatable.  ("It's
>supports ARexx, but does it support Browser?")
>
	I had hoped this controversy would have stayed quiet until I could
have thought of an elegant mechanism for this.  I have the beginnings of it,
but it's not at all completely worked out.

>IPC1 - Interprocess Communication Standard (Proposal)
>
>The basic design is derived from the EA IFF 85 standard, since that has
>worked so well and lots of Amiga users already understand it.
>			    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	HAAAAHAHAHAHAHAHAHAHAHAHA.......

	IFF is one of the most byzantine "things" ever created.  It is
extremely difficult to parse (if you want to be "truly compatible"), and no
one uses the same piece of code to read or write it.  Everyone avoids EA's
published code, since it's so vile.

	Stuart then goes on to describe the data exchange format.

	I've been thinking about this problem for a while, since I've had to
address it directly and indirectly a number of times over the past few
months.  I've been trying to come up with an elegant solution.

	UNIX achieves IPC (usually) through pipes.  One program's stdout is
connected to another program's stdin.  On UNIX, this works great since, in
most cases, all user I/O through the program is through stdin and stdout.

	On the Amiga, however, this is not the case.  User interaction may
come through stdin.  More often than not, however, it comes through
the IDCMP port.  No assumptions can be made about what's coming through the
IDCMP port, since primary user interaction may be anything from RAWKEY
events, to menu events, to gadget events, to morse code tapped in on the
mouse button.

	The only solution to this dichotomy of user interaction methods is
to define a new message port.  The sole purpose of this port is to accept
standardized commands from outside.  As I'm led to believe, this is how
ARexx does it currently.  However, ARexx does not establish a standard
command format.

	I used to believe that the only requirement would be some sort of
command port, and document its use.  It would be the responsibility of
external programs to abide by the established protcol.  Taking this method
to its logical conclusion, I ended up with a very messy rat's nest of user
scripts, making things unreliable.  So a free-for-all in terms of command
structure won't work.

	I'm still working out the actual command structure.  I'm trying to
consider all the things that a programmer or user will want to do, and
provide a facility for it.  I also want to keep the spec open, in case I
left something out, and I also want the spec to seem familiar (i.e. based on
an existing Amiga facility) so that a new mess of procedures will not have
to be learned.

	Stuart was trying to address data exchange.  This is only a minor
part of the whole problem.  The primary requirement is getting programs to
*do* something outside of normal user interaction.  One of these commands
could be to dump its data.  The format of the data should be the problem of
the program asking for it (this is how it is currently).

	Data format exchange standards should not be worried about just yet.
We have to establish a method of communication and "remote control" first.
Once we get the remote controls in, then everything will be possible.

	If Sculpt and VideoScape had remote control ports, the John Foust's
Interchange program could be nothing more than an ARexx script.

	Gimme some time; I'll try and cook something up.  Who knows?  It may
actually be worth something.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor