Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!mailrus!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga
Subject: Re: IPC (1): Ports & Messages
Message-ID: <7590@agate.BERKELEY.EDU>
Date: 11 Mar 88 08:24:53 GMT
References: <7412@agate.BERKELEY.EDU> <752@nuchat.UUCP> <1948@dino.ulowell.edu>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP (Pete Goodeve)
Organization: University of California, Berkeley
Lines: 55
Keywords: InterProgram Communication, tools
Summary: Welcome, Bill...!



> I've had a chance to read and digest some of the ongoing IPC thread and
> have a number of comments and suggestions to add.  First an introduction:
> I'm Bill Hawes, perpetrator of ARexx (and ConMan, and WShell, and ...)

Hey Bill... Welcome to the net! And about time!  Now that you're here, I
have a couple of quick questions:

> ARexx marks its messages with the string "REXX" in the ln_Name field of
> the message, so you can easily tell whether it comes from a REXX macro.

Is there a pointer to the STRING "REXX" in the ln_name field, or is this
just those four characters inserted into the longword?  For some reason, in
all our discussions, we've forgotten about this field (though I've just
been suggesting it's use to mark ports).  This location could probably
perfectly well be used for our proposed four-character message-type ID,
rather than a pointer to a string.  If you happen to do it that way, we'd
have immediate compatibility, with "REXX" being one of the possible message
types in a more general scheme.  [And if you DON'T do it that way, would
you consider changing? :-)]

[Does anyone see any problem with using this field in this way? I've never
seen anyone want to name a message, actually, though I think a pointer to
sundry special data has sometimes been put there.]

I still feel strongly that the RexxMsg format is inappropriate for a lot --
if not most -- of the message passing that interacting processes that
didn't use Rexx would want to do.   We want something initially as
unstructured as possible, yet formalized enough so that a program can know
what action to take.


As to the Rexx language itself, my main feeling is that we don't want to
lock out other possibilities at this stage.  We all know that preferences
in the computer field are largely religous, so it would be nice to have
variety for people to choose their favorites from.  Any you can tell from
the way that the discussion has been going that a few people would like to
have a crack!

I have one question here too: is Rexx single threaded, or is there some way
that several processes can have scripts active at once?


> The issue of standardized commands is important, but imagine the howls of
> outrage had I attempted to dictate what commands an editor, a database,
> and a paint program should support!  The command set should be decided by
> the program's developer, ideally in conjunction with other developers of
> related (re: competing) products.

No disagreement here.  (But -- repeating myself one more time -- I think
the same goes for message formats, except that to be useful these must
really be determined by consensus.)

                                            -- Pete --