Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga
Subject: IPC - A proposal
Message-ID: <5375@well.UUCP>
Date: 5 Mar 88 10:35:32 GMT
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 109
Summary: Yeah, let's do it!


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?")

Lets get on the ball now and *design* a standard before one gets designed
for us.  The potential rewards are enormous, and the costs are just the
effort to get it started and the extra programming effort for everyone to
use it, and that is distributed over a large number of programmers over a
large period of time, so the individual cost is small.

The reward is an integrated environment without equal.  An interprocess
communication standard is not just another linear development, but has very
non-linear effects, leveraging each component of the system against the
others.  Multi-tasking multiplies the power of individual tools together.
An interprocess communication standard promises to multiply them again.

Ok, ok.  Enough hype.  You get the idea that I'm really excited by the idea?
Good.  I am.  Here's a first cut at it ...

------

IPC1 - Interprocess Communication Standard (Proposal)

This describes the format for a standard message block.  The format is
general enough to allow for any type of data necessary to be included in the
message, but is also restrictive enough to prevent many errors and to
provide for upward compatability.  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.

The standard message block has the form:

   struct GenericMessage {
      struct Message gm_mess;
      ID magic_code;
      long gm_size;
      ID gm_code;
      char gm_body [ /* value of gm_size - 4 */ ];
   }

where "ID" is a four-byte integer (i.e., a "long").  The possible values
for gm_code are defined the same way as the Chunk ID's for an IFF file,
namely, 4 characters from a certain range of ASCII codes concatenated 
together.  Trailing spaces are permitted.  The "ID" value magic_code shall
be the characters "IPC1" encoded this way, and will be the way for
programs to identify standard message blocks.   The value of gm_size is the
size in bytes of the message block starting with the byte AFTER the last
byte of the gm_size field itself (like IFF files).

Gm_code will a 4 character ID code, and the standard definition should
include some preset values for general message types.  There may also be
code values that all tasks chosing to support the IPC1 protocol will have
to know how to answer.

The "body" of the message, gm_body, will consist of zero or more "Chunks" in
series, each one starting on the first even byte after the previous one.
Chunks are defined as:

   struct Chunk {
      ID chunk_id;
      long chunk_size;
      char chunk_body [ /* value of chunk_size */ ];
   }

The meaning of the data in chunk_body depends on the value of chunk_id as
well as the value of gm_code.  The data in chunk_body are positionally
defined.

The nested chunk design allows for future expansion so that the data that
can be passed in a message can change without breaking programs that only
understand the unexpanded message.  Parsing this structure is almost
trivial, and ignoring unrecognized chunks is as simple as skipping over
them.

Other issues:

This is just a first attempt at attacking just one part of the problem of
defining an interprocess communication standard.  There are other issues
that should be addressed:

   1. What is the communication model to be?  Clients & servers?
      Asyncronous free-for-all?  Other ideas?

   2. What are some important message classes to define as standard?  What
      message does everyone have to understand?

   3. How do the public named message ports figure into all of this,
      especially question number 1?

   4. Can devices be folded in as a special case, or should they just be
      regarded as their own standard?

Also, just hashing out a good idea won't make it a standard.  It will
require some software that uses it, as well as some cooperation from the
software people at Commodore.  Any ideas about how to go about the "public
relations" part of the standards design?

All too often we get stuck with short-sighted or limiting "de-facto"
standards more or less by accident (the IBM PC is a good example).  Let's
not let this happen this time.  Thanx for the bandwidth.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)