Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!arizona!rogerh
From: rogerh@arizona.edu (Roger Hayes)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPCMessages -- A Prototype
Keywords: IPC, standard, data
Message-ID: <5925@megaron.arizona.edu>
Date: 20 Jun 88 17:35:04 GMT
References: <6306@well.UUCP>
Reply-To: rogerh@arizona.edu (Roger Hayes)
Organization: University of Arizona, Tucson
Lines: 35

In article <6306@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
>...  The problem is that IPCMessages do not
>provide for standardized data formats.  They deal with standard
>_message_ formats reasonably well, but data is handled very
>incompletely.  Peter ran into this very problem himself in implementing
>his slide show program(s) and kludged around it. 
>

Stuart goes on to suggest "abstract data types", such as bitmaps, for
data.  I would like to offer a slightly different suggestion.

IPC messages should be easy to use from our programming languages, so
they should contain data of the familiar types (int, float, string) and
type constructors (record, array).  To be most useful on the Amiga,
they might also have special constructs for the common Amiga data
structures (like Port or Bitmap).

We gain the most flexibility if the IPC ports can be connected freely
at runtime, without compiling the two ends together.  In order to do
this while preserving the meaning of the data, messages should be
self-describing.  That is, an int value is preceded by a tag that says
'INT'.

If anyone is intrigued by this idea, I have it implemented in C for
Unix.  The system includes a stub generator for remote procedure calls,
data translation routines, and a rudimentary execution manager.  The
code is *not* production quality.

I'm not planning to port it to the Amiga myself, as I've promised my
advisor that I won't get an Amiga compiler until I am done with my
dissertation.  If anyone is seriously interested in doing so, write me
for details.

				Roger Hayes
				rogerh@arizona.edu