Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Shared IDCMP Ports--Proposal
Message-ID: <8810191748.AA01195@cory.Berkeley.EDU>
Date: 19 Oct 88 17:48:15 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 42

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

	I see it, it's a cool idea because then the IPC is immediately 
window-oriented.... more intuitive to the user, no?  One could then construct
'standard' commands to cut-paste text and IFF, etc... without having to go
through the bother of the clipboard.

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

	Hmm... the problem is that DOS has to be fixed first.  Asynchronous
incomming messages simply do not work on pr_MsgPort because DOS expects the
reply to its synchronous packet to be the next packet that comes back on
the port, which is stupid since a WaitMsg() call is just as easy to write
as a WaitIO() is for IO.  Right now DOS simply does a WaitPort() and GetMsg().
BTW, I have a WaitMsg() call in my new DRES.LIBRARY which is being released
soon (now being uploaded from my Amiga so the moderator can FTP it).

	-) It's kind of fun to be able to log in to my UNIX acct from home,
start a 2MB transfer (via DNET) and have it crunch on it while I'm at class.

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

	I wish it were possible, but alas.

	Actually, I think it would be better to EXTEND the window structure
in 1.4 and add another port, as well as fix the way IDCMP ports work now 
so one can share them more easily.

				-Matt