🚀 go-pugleaf

In article <7412@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)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,

  beep-beep beep beep-beep beep

)but I fail to see why everyone
)is keen on making IPC connections through a Window's IDCMP port.

I actually share this position, but:
1) There are some good reasons, the most compelling being automatic
  serialization of input and "input equivalent" ipc.

2) It's more convenient, although not by much.

3) (key point) If IPC from different services will EVER be able to
  be received at a common port, some standard for differentiating
  them will be needed.  Although it's kind of weird to differentiate
  a possible IDCMP message, it's safe, usable, and ALLOWS the use of 
  an IDCMP port, which has advantages.

  I think that where you are off-axis below is where you infer
  that being able to use the IDCMP means something special to programs.

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

Easy to clear this up: IPC messages should (in ANY standard!!) be sent
to a port you somehow register with a service (minimally, AddPort()).

The proposal is for how you might be ABLE to register the same port
for IPC as you are using for IDCMP, whether you create/delete it or
does Intuition.  I think this is the misunderstanding.


)	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.

But they're not guaranteed to have anybody listening.  Frankly, I
don't understand the complete use of pr_MsgPort.  It would be worthwhile
to consider if ALL your messages, IPC, process related, and IDCMP could
come to the same port (which would have to be pr_MsgPort).  (I guess 
device reply messages is asking a little too much.)

)	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:

Wrong assumption.

)	/*
)	 * 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;

ARRGH ARRGH ARRGH!!!  (exclamation of some concern)

Nobody says that the port you use for IDCMP must be created by Intuition,
nor that it must be PA_SIGNAL.  That is to say, NO REASON TO ASSUME THAT
mp_SigTask is a valid task (and even then no reason to believe it
is a process).

)	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()).

This is not an issue here, but is an interesting issue.  It turns out
that GetPrefs() is NOT a DOS call (dos, at init, reads devs:s-c and
calls SetPrefs(), an Intuition function).  HOWEVER, there are coming to
light a NUMBER of things that subtly require you to be a process, such
as OpenLibrary().  The first one to bite me was OpenDiskFont(), called
before DOS was really ready to do disk I/O, even though I was supposed
to be running as a process at the time.  Someday, SetPrefs() might
require Intuition to call OpenDiskfont().  As Peter (of the Wolf's)
father (or uncle) said: "What Then?"

)	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 strongly oppose ever sending a message to someone who didn't ask for it.
Besides the obvious problems, it probably means that there is no guarantee
that the sucker is still planning on replying your messages.

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

Now, I don't think this is too wise, in the interest of robust code.
Not much weirder than the Guru Meditation, I suppose, ...

)>	We are debating whether
)>	the ID should be 8 or sixteen bits.  [ ... ]
)
)	I prefer sixteen.  I'd even more prefer 32.

Duly noted.  Thanks for reading and commenting on the proposal.

)	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
-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are not to be taken as Commodore official policy.