Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!alberta!ubc-cs!van-bc!root
From: lphillips@lpami.van-bc.UUCP (Larry Phillips)
Newsgroups: comp.sys.amiga
Subject: Re: Time is of the essence on IPC.
Message-ID: <1714@van-bc.UUCP>
Date: 17 Apr 88 02:20:14 GMT
Sender: root@van-bc.UUCP
Lines: 139

In <1831@sugar.UUCP>, Peter da Silva writes:
>> [ some stuff from me about pipes in Conman being OK ]

 > Well, that's not what I was talking about. I'm not saying that the shell
 > shouldn't do that... I'm just saying that the actual pipe handler should
 > not be an magic part of another program. Rather, it should be something
 > that DOS formally knows about. Of course in the current version
 > of ConMan it is, but I didn't know that... not having a recent copy.

 > But I feel better know that I know that I'm not the only one who's gotten
 > confused on this subject :->.

OK.. I go along with that. The most recent Conman is really quite nice.
The biggest problem with pipes at this time is the lack of programs suitable as
filters. With ARexx, they are easy to write (and to modify for special cases).
'head' and 'tee' are two that were included as samples on the WShell disk.

>> First, ARexx ports in a program do not necessarily need ARexx in order for
>> another program to use them. If an editor has an ARexx interface that
>> allows commands to be passed to it, any program can do a FindPort and send
>> commands.

 > OK, but does any program other than ARexx actually do that? And I thought
 > that a program's AREXX port was supposed to have a unique number tagged onto
 > the end of it, so how's FindPort supposed to find it (of course I could be
 > totally confused about *this*).

Probably not at this time, but with the documentation provided, you can write
programs that use an ARexx port in any program. FindPort can be used to find
the port by name. As far as I can see, the name of the port is as stated in the
program opening the port. There is a unique identifier mentioned, but sounds
like it's part of a message packet in case a message port is being shared.

 > Remember, whatever we come up with has to be usable by non-programmers.

Well, sort of... actually, ARexx programs and those programs employing an ARexx
interface need to be usable by non-programmers. This is no different from
the Amiga in general. Until software is written, only programmers use the
machine. One thing though... many people are somewhere in between programmers
and users. Given a simple, easy to use, interpreted language, there will be a
lot of programs written that would otherwise not have been considered. (I
wouldn't say they will all be top quality :-) )

>> It seems to me that the IPC protocol being spoken of on the net
>> will do exactly the same thing.

 > It will also allow you to define a common pool of tagged message types that
 > programs can use or ignore as they see fit, rather like IFF.

Yes, and ARexx would serve as a good base for such things. I don't know if I
understand enough of the implications of the IPC being talked about, or the
suitability of ARexx as part of this, but I would hope that any standard
settled upon will be compatible with ARexx. I don't know of anyone using it who
doesn't like it, and think that it will become somewhat of a standard, or as
much of a standard as a commercial program can become.

>> Second, allowing a programming language, especially a script/macro
>> interpreter to do the calling (and to accept commands, data, or status back
>> from a program) is a great way to make the facility even more powerful by
>> allowing the user, rather than only the programmer, to specify how any two
>> programs will interact

 > Fine, but it should be up to the user to decide what that language should be.

ARexx just happens to have that facility, now, today, and works well. Someone
could write a similar one using a language other than ARexx, or could write
some sort of completely compatible language that uses existing ARexx
conventions. One important thing to remember is that there are a number of
cmmercial and non-commercial programs that offer an ARexx interface now, today,
and that work well. Personally, unless a substitute offered a lot more, and in
addition, had as much support in programs, I wouldn't be mnuch interested.

>> The ARexx interface is well documented. All you need to do from any program
>> is a FindPort, then start sending messages that conform to the interface
>> spec.  Of course with the type of IPC being discussed here recently, all
>> you would have to do is a FindPort, then start sending messages that
>> conform to the interface spec.

 > And it shares the same problem. You're confused again... or is it just that
 > you don't see why I would want to interface an existing program to this...
 > like, say, DeluxePaint.

Perhaps I am confused, perhaps not. I can certainly see how you would like to
interface an existing program, but the problem is that there are no mechanism
in most existing programs for commanding them from another program. The only
way I see to do this would be to use something like 'journal' or 'copilot' to
drive the keyboard and mouse to make the program do what you need. As far as
allowing programs to interact in a more general sense, I am all for it. I
commented at a user group meeting that _I_ couldn't see a need to have Pro MIDI
Studio, Dpaint, and TxED interact, but that if they all could interact,
_someone_ would undoubtedly find a use for doing it.

>>> One of the items on my stack of things to do when I have time is a CON:
>>> type handler that provides ANSI-style escape sequences to do things like:

>>>	Menus.
>>>	Function keys.
>>>	Graphics (probably based on DEC Regis graphics).
>>>	Changing the title bar.
>>>	Adding a close box (that sends ^C).
>>>	Scroll bars like the Bridge Card software's windows.

>>> And with a clipboard interface. That's the sort of thing that a CON: device
>>> needs.

 >> Sounds a lot like the things you can do with WShell and ARexx.

 > Really? In a standard console window running UNIX-type CLI-only programs that
 > haven't been Amiga-ized? Or remotely via a terminal program like Matt
 > Dillon's DTerm that opens a console window to do its rendering? Amazing.

Perhaps I have misunderstood your meaning. With ARexx, WShell, and Conman
running, I have the ability to set the title bar in an amazing number of ways
(all things that the prompt can have), open windows and write/read to/from
them, and close a CLI with the close box provided. Other programs do a lot of
things that you mention, and of course can be called from an ARexx program. The
clipboard is supported (I'd have to dig for the details). I suspect you are
thinking along the lines of extending 'Browser', and I commend your present
efforts on and further development of that program. I do think though, that
ARexx is not quite what you think it is, and look forward to hearing your
comments after you've used it.

>> Plug here for Matt's program. It's very Zen.

I was never able to get DTerm to operate from scripts. It would not
recognize incoming strings. Too bad, because I really like the idea of driving
things with a state machine, and the script capabilities of STerm look awesome
on paper.

-larry

--
Janus? Well, look at it this way. If you squint a little, the J could be
       Amiga checkmark, and the rest of the word describes MsDos.
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+