🚀 go-pugleaf

Eight THOUSAND unread messages in comp.sys.amiga!?!  I know I haven't
been on for a little while, but...jeez...


Well, hi again!  I've come back to look in on the IPC conversations that
I've been hearing about.  I've spent some time following all of the
related threads that I could find;  and, I have an important point to make
as a bonafide commercial developer with a real commercial product
(Microfiche Filer).  

     LATER IN THIS MESSAGE I'M GOING TO ASK YOU FOR
YOUR COMMENTS CONCERNING A HIGH LEVEL STANDARD.  YOUR SUGGESTIONS MIGHT
ACTUALLY MAKE IT INTO A COMMERCIAL PRODUCT!

First of all, there were some very interesting ideas expressed about
an object oriented system, an IFF based system, a device based system,
a broadcast message system, function servers, name servers, and so on.
The discussions have ranged from the highest levels to the lowest
(and I must smile about the fact that some people were seriously examining
the subject of FindPort being too slow, while the messages contained
IFF format structures, the parsing of which would dwarf the time needed
to do a FindPort! :-).

I would like to point out that there already exists a low and medium
level standard that is sufficiently powerful to mediate conversations
between applications and provide control mechanisms - AREXX!  ARexx may not
be THE perfect solution (I personally have some problems with the
language syntax), but it does meet the 'sufficiently powerful' test
by being fully programmable and allowing the passing of ANY data in
ANY format between concurrently running applications.

It has another overwhelming benefit:  it exists TODAY as a commercial
product with the support of Bill Hawes, ace programmer!  This alone
carries great weight with me, a commercial developer with a commercial
product longing for this type of interprocess communication and data
transfer.

It is more than longing, though;  the code to support ARexx is going
into Microfiche Filer II even as we speak!


      My challenge is this:

Let's assume in this message thread that Arexx is the low and medium
level message passing standard.  It already exists and is, in fact,
being used in several commercial products already.

      SO LET'S DESIGN A HIGH LEVEL STANDARD!

A few definitions:

MACRO - an ARexx program that can invoke other macros or communicate
        with programs.

PROGRAM - a piece of software that has opened some rexx message ports,
          can invoke macros and can perhaps act as a server.

In the rexx system, communication is not symmetrical.  Programs can
invoke macros and macros can command programs.  However, programs cannot
command macros (other than by passing parameters upon startup or by
responding to a message from the macro).

A message sent from a macro is synchronous.  The macro does not regain
control until the program has responded.

A message sent from a program invoking a macro is asynchronous.  The
program may go on doing anything it pleases until it receives a message
from the macro or until the original message is replied.

However, in the rexx interface of Microfiche Filer, I have found it
to be advantageous to deal with macros in two ways: as a server (handling
single harmless requests from macros immediately), and as a synchronous
slave (by invoking a macro and allowing no input except USER ABORT and
macro commands until the macro has completed it's task).

Nearly all commands currently accepted by Microfiche Filer are atomic;
they complete their task and return immediately with the result or
an error code.  Several notable exceptions are "DISPLAY", "REQUEST", and
"STRING_REQUEST", which ask for user input, and the printing commands.

Simple YES/NO type information is returned as an error code, simple
string information is returned using rexx's RESULT string handling,
but the most interesting information is passed around in compound
variables.

Compound variables are able to contain groups of information, similar
to structures and arrays.  This information can be passed between
programs and macros with a single reference.

Well...This is getting quite long.  Let's just leave off here and see
what you have to say about this, so far.

Remember...Everything described here is already working in Microfiche
Filer II...So let's discuss not whether it's feasable or how efficient
it is, but how it can be used in interesting ways!


	cu,
	Gary