Path: utzoo!attcan!uunet!cbmvax!rutgers!apple!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Shared IDCMP Ports--Proposal
Summary: Queries...
Message-ID: <7412@well.UUCP>
Date: 19 Oct 88 06:31:43 GMT
References: <3031@amiga.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Nothing to do with Pixar.
Lines: 77
Quote: "Hey, really.  I'm serious.  'Gilligans Island' gives me kidney stones."

In article <3031@amiga.UUCP> jimm@amiga.UUCP (Jim Mackraz) writes:
>	----- Shared IDCMP Ports -----
>
>    At the request of developers, we've tried to develop a standard by
>    which users may use their Window IDCMP port for other Inter-Process
>    Communication (IPC).
>
>    Here is an explanation of the issues and a tentative proposal.  As
>    a developer, your feedback is important and welcome.  Note that
>    these standards, when blessed, can be used immediately.  There
>    is no need to wait for V1.4 once conventions are established.
>
	I hope I'm not from Mars on this one, but I fail to see why everyone
is keen on making IPC connections through a Window's IDCMP port.

	Consider:  Not all programs open windows (the CLI commands are good
examples of this).  Some programs which do open windows open only DOS
windows, for which IDCMP access is at best difficult, and handled by DOS
anyway (and knowing DOS, it will probably get seriously confused if foreign
messages start arriving at ports it manages).  Also, some programs open more
than one window; how do you know which IDCMP port to send it to?

	I feel that IPC communication should occur through a process's
pr_MsgPort.  All processes are guaranteed to have one and only one, they're
always in the same place, and they're guaranteed to exist as long as the
process exists.

	If the reason you want to connect via windows is so that the user
can send a control message to a given process by simply pointing to a window
and clicking on it, then you can still do it with process pr_MsgPorts:

	/*
	 * User clicks in window, and a pointer to this window is left
	 * in win.
	 */
	struct Window	*win;
	struct Process	*pr;
	struct Widget	*IPCCommand;

	win = FindWindowUserClickedIn ();
	pr = (struct Process *) win -> UserPort -> mp_SigTask;
	PutMsg (pr -> pr_MsgPort, IPCCommand);

	This will, in general, map to the same process no matter how many
Windows a process opens.  There may be an issue with programs that "fork"
processes to handle windows, but this would not be changed going through
IDCMP ports.

	The only real issue is what to do with tasks (not processes) that
open Windows.  The "obvious" solution is to require that only processes open
Windows.  This is already more or less the case, since Intuition can
indirectly call DOS (via GetPrefs()).

	Another thought occurs to me:  Perhaps the reason you want to go
through the IDCMP port is so that programs that don't support IPC but get
sent IPC messages will simply ignore and return them.  I don't see how this
could be made to work elegantly for the pr_MsgPort (DOS currently throws up
a deadend alert if it's waiting for one kind of packet and something foriegn
arrives).  However, you may wish to consider that some programmers, like
me, have the following statement in their event switch () loop:

	case default:
		die ("OOPS!  Unknown IDCMP msg received.\n");

>	We are debating whether
>	the ID should be 8 or sixteen bits.  [ ... ]

	I prefer sixteen.  I'd even more prefer 32.

	Anyway, that's my two cents.  I *am* interested in knowing why the
IDCMP port is so popular.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor