Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <8803052355.AA29899@cory.Berkeley.EDU>
Date: 5 Mar 88 23:55:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 77


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

	I agree, but let's do it right.  One reason the clipboard device
never caught on (to non-commercial programs) is that it is difficult to
use.

	ARexx is interesting, but also somewhat convoluted and takes too
much overhead. It doesn't have as much power as I would like.

	Whatever we decide on, it must be made relatively easy to use.
But we don't simply want a stream oriented IPC.   People don't take enough
time to think of easy ways to provide maximum power and capability. 
This is what I envision:

	-Low per-task memory overhead

	-Symbolic Asynchronous Remote-Control capability (domain based)
	 e.g. one application can send symbolic commands to another...
	 A data stream, as part of a command, would be a minor item in
	 this system.

	 (DME.file1(unblock block block) DME.file2(bcopy))

	 (DME.file1(saveas ram:x) TEXTED(File-Open ram:x)) CLI(Delete ram:x))

	 Also, have a standard format for SARC menu item simulation.
	 e.g. DME(File-Quit)

	-Macro Expansion capability (which is a superset of what ARexx 
	 would give us) e.g. program X gives the driver a symbolic macro 
	 which the driver executes, possibly causing remote-control
	 commands be sent back to program X and/or to other applications.

	-Fully reentrant and stackable remote commands, with infinite
	 loop detection, etc... without taking a huge amount of 
	 overhead.

	 e.g. program X sends a Macro to the driver, which sends resolved
	 commands back to program X which just happen to be macros in
	 program X which is expanded again and sent as a Macro to the
	 driver, which sends resolved commands to program's X and Y,
	 program X executing the command, etc....  

	 Also allowing program X to handle such things synchronously or
	 asynchronously (not wait for macro completion before continuing,
	 but not getting confused either).

	-Error recovery... so things don't freeze up.

	-Exit recovery.  Allow program X to exit at any time without 
	 screwing up any macro's in progress (have them gracefully fall
	 to their deaths).  i.e. calling SarcClose() clears anything
	 pending.

	-Standard command format.  Ability to specify logical or physical
	 streams (i.e. supply your own functions or use DOS functions,
	 etc...).

	-Low level IFF decoder for arbitrary IFF streams.  Since IFF is
	 structured, the decoder would not have to know specific formats,
	
	-Ditto Low level IFF encoder for arbitrary IFF chunks.. Structures
	 the chunks for you.

	-Run time Library to handle interaction.

	I could work on something like this after I get DNET out.

						-Matt