jimm@amiga.UUCP (Jim Mackraz) (10/18/88)
----- 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.
----- IDCMP Basics -----
The important things about a Window's IDCMP port are how it's created,
how it's deleted, and what happens in the meantime.
An IDCMP port (and a freshly allocated signal) is created when you
open a window with non-zero IDCMPFlags, or when you call ModifyIDCMP
with non-zero IDCMPFlags and there is no port already.
An IDCMP port is deleted when you close a window and the IDCMP port
exists (and is pointed to by Window.UserPort), or if it exists when
you call ModifyIDCMP with zero IDCMPFlags. When Intuition closes
down a port, it assumes that all messages on that port are
IntuiMessages. For each message, it removes it from the port,
sets its IntuiMessage.Code field to OKABORT, and ReplyMsg's it.
This isn't all that bad. At least your messages hanging off of
the IDCMP port will be replied to you.
We will not guarantee that the OKABORT step will be taken, but you
cannot count on ANYTHING about the "Code" field of a message being
replied from an IDCMP port.
Messages will be sent to an IDCMP port on an unpredictable schedule
from Intuition. The primary identification of such messages is
the first long word, the Class field for IntuiMessages. We can
reserve a value for this Class field for non-Intuition traffic.
----- Sharing Ports, In General -----
Even were Intuition not in the loop, there are some general problems
servicing several senders of messages at a single port. The first
is identification, and the second is unserviced leftover messages.
It's easy to agree on a field that will contain an ID which identifies
which service sent a message, but how are those ID's defined? We
propose that they be defined by the receiver program. That is,
when you register a port with a message sending service, you will
specify an ID which you want included in every message that the
service sends you. Typically, you will be able to make constant
assignments for different services without complication.
The way to handle leftover messages is to reply to all the messages
sent by a service when you are done with the service. Note that first
you must tell the service to stop sending you more messages, the
service cannot go away completely (deallocating its reply port) until
you have replied all the messages, and that you must Forbid or otherwise
inhibit other services from sending messages to that port if you
are walking down the message list and selectively replying to messages
from a particular service.
----- Specific Proposals for IDCMP Compatible IPC Messages -----
A service which is sending IPC messages which can be safely received
at an IDCMP port must follow the following conventions:
Registration of Port/ID:
It is assumed that a message sending service is a library or device,
or a permanent module. This is so that there is time to reply
accumulated messages after you "de-register" your port. So,
OpenLibrary or the equivalent guarantees the existence of the
services reply port until CloseLibrary is called, for example.
When specifying that you want messages sent to you for some
reason, you "register" your port with the service, typically
through a library call. In so doing, you provide an 8 or
sixteen bit ID (haven't decided yet). It is the responsibility
of the service to keep that ID associated with the port
you have registered and to copy it into each message (see
below).
The ID will need to be copied into each message every time
it is sent, since it is possible and likely that the ID
field will be corrupted by the receiver (due to interaction
with Intuition). See below for more comments on message format.
Shut Down:
There must be a "de-register" function as well, or some other
method of insuring that no further messages will be sent
from a given service to a given port. This function must be
synchronous: not even one single message must be issued after
this call has returned.
It must continue to be safe to ReplyMsg messages sent from
a service AFTER the port has been de-registered, such as until
a CloseLibrary call has been made.
Format:
The message must begin with a format that mimics the beginning
of an IDCMP message:
struct IPCHeader
{
struct Message ExecMessage;
ULONG Class;
USHORT Code;
};
For non-Intuition messages, Class will always be the same value,
somthing like IDCMPUSER. Code will contain a copy of the
of the registration ID provided above. We are debating whether
the ID should be 8 or sixteen bits. If it is eight, then
it can be put in the high-order byte of Code accompanied by
a command code in the low order byte. This would let people
write programs with one fewer levels of switch statement. The
downside is that it reduces the ID space to 256 simultaneous
services.
Examples:
/* ID is 16 bits, entire Code field */
switch ( imsg->Class )
case IDCMPUSER:
switch ( imsg->Code )
case SERVICEA:
switch ( imsg->customcommanddata )
case SERVICEA_COMMAND1:
case SERVICEA_COMMAND2:
This could become, with an eight bit ID:
/* ID is 8 bits, in high byte of Code field */
switch ( imsg->Class )
case IDCMPUSER:
switch ( imsg->Code )
case (SERVICEA << 8) | SERVICEA_COMMAND:
Is it worth it?
----- Using an IDCMP port for Other Purposes -----
If you want to use an IDCMP port managed (created, deleted) by
Intuition, you must take the following steps:
Once Intuition creates the port (OpenWindow, ModifyIDCMP) register
the port with the IPC service. Never let Intuition delete that
port while it is registered with another service.
Handle the IDCMPUSER messages as described above.
When you want the port deleted (CloseWindow, ModifyIDCMP),
first de-register the port with all services. Then CloseWindow,
and lastly close the services libraries. This sequence insures that
Intuition's replying of any leftover IDCMPUSER messages will
send them to a valid port. A conforming server will not have
a problem with the fact that Intuition clobbers the Code field
when it replies messages in these circumstances.
----- Using a port of your own for IDCMP -----
This is a little trickier. The problem is that you don't want
Intuition to delete your port when you CloseWindow (or ModifyIDCMP),
so you have to remove it before you shut down the IDCMP traffic.
But this will prevent Intuition from clearing the traffic (replying
all your messages) so there may be outstanding IntuiMessages hanging
off of the port.
Now if you leave them hanging and close your window, Intuition will
free their memory, and you will be left with a message chain linked
through free memory; not a happy situation.
The way you handle this is to remove the port from the Window
(Window.UserPort = NULL), ModifyIDCMP(NULL) (Intuition will not try
to free your NULL port), and while forbidden, walk the message port
list removing and replying all Intuition messages. Since you
have shut off further traffic by ModifyIDCMP, you are now in a safe
state for calling CloseWindow.
----- Using a single port for multiple windows -----
This is simply using your own port for IDCMP, but for more than
one window. The sequence of closing a window is the same, but
you must take care to remove and reply only those IDCMP messages
which were directed at the window you are trying to close.
This is done in a demonstration named CloseWindowSafely(), which
we will repost in a final draft of this standard. It needs no
change to support messages arriving at the port from non-Intuition
IPC services.
--
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.peter@sugar.uu.net (Peter da Silva) (10/19/88)
In article <3031@amiga.UUCP>, jimm@amiga.UUCP (Jim Mackraz) writes: > 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). First reaction... blech. After reading further... hey, this is a cool idea! > We are debating whether > the ID should be 8 or sixteen bits. If it is eight, then > it can be put in the high-order byte of Code accompanied by > a command code in the low order byte. This would let people > write programs with one fewer levels of switch statement. The > downside is that it reduces the ID space to 256 simultaneous > services. Since the ID is generated by the program that registers the port, that's 256 simultaneous services per program. Should be more than ample. > This could become, with an eight bit ID: > /* ID is 8 bits, in high byte of Code field */ Put it in the low 8 bits, so that services that don't have any ids can do the job. > Is it worth it? Maybe, maybe not. It's pretty irrelevent, since the subcode can be put in the Qualifier field. I would like to require that the structure be the same size as the IntuiMsg structure, to allow for programs that do a structure assign and replymsg immediately after the getmsg as a matter of course. How about this scenario: you register with Browser by passing it the address of your IDCMP. From then on people can drag files into your window from browser. You'll get an IntuiMsg with IAddress pointing to a struct WBStartup containing the files dragged into your window in the WBArgs. Question: can I depend on the IAddress being unmunged by Intuition when I get the replymessage? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/19/88)
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
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/20/88)
> 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
jimm@amiga.UUCP (Jim Mackraz) (10/20/88)
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.
jesup@cbmvax.UUCP (Randell Jesup) (10/20/88)
In article <7412@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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? No one said you had to send the messages to a real IDCMP port. You can use a private port if you wish (any port at all - just CreatePort() it). > 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. I can see you've never written a dos handler. :-) If you had, you'd know about AN_AYNCHPACKET, the error dos gives if it finds a packet it doesn't like. > 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: No, this has nothing to do with it. You have to request a server to send you packets, they won't do it spontaneously. -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (10/20/88)
In article <7412@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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. And I believe dos.library already uses this port... and has conniption fits if it gets the wrong message coming in on it. > 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). Oh, you already know that. > Anyway, that's my two cents. I *am* interested in knowing why the > IDCMP port is so popular. It comes for free with every window and it doesn't lead to DOS guruing you. Personally, I prefer allocating a new port for this purpose. It's easy enough, after all, but if CBM is gonna bless this particular form of IPC it's got a BIG advantage over PPIPC, OOIPC, DIPC, and maybe even REXX. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
papa@pollux.usc.edu (Marco Papa) (10/20/88)
In article <5044@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software ^^^^ ^^^^ Very funny, Randell. So now give us the lineup of DOGS. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
daveb@cbmvax.UUCP (Dave Berezowski) (10/20/88)
In article <12937@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >In article <5044@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >>You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software > ^^^^ ^^^^ > >Very funny, Randell. So now give us the lineup of DOGS. > Let's see now.............................. Andy Finkel, Eric Cotton, David Berezowski, Steve Beats, Bryce Nesbitt, and Randel Jesup (in no specific order). Of course there are also the west coast contingents...... Jim Makraz, Dale Luck, Bob 'Kodiak' Burns, and Bart Whitebrook.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/22/88)
In article <3037@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >In article <7412@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >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. > Oh, I get it. IPC can occur through any port I care to name, including the IDCMP port if I so desire. And I won't get IPC messages unless I register my port. I guess the reason I'm having difficulty understanding all this in one pass is that I've had my own vision of an IPC system for some time, but I guess I never imparted it correctly, because no one seemed to like it. My vision was that *every* program would respond to a defined set of coded commands (read, write, stop, etc.). The idea was that all programs would respond in the appropriate way when sent the command. This means that you could write a script that did a generic thing, and apply it to all the programs you had without modifying it. Since all programs would be doing this, and all programs obeyed the same exact commands, connection would take place through the pr_MsgPort. To send a command to a program, you'd look it up in Exec's list of running tasks (checking to be sure it's a process first), and send it a command. Well, *I* thought it was neat... >) 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). > Oh, great. Does this mean Intuition uses some other method of Signal()ing me when a message is ready? >) 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, ... > I usually put it in for debugging reasons, and then never bother to take it out since it's "never" going to get called anyway. It's helped *me* out on a few occasions. And my die() routines are scientifically designed to kill the program coherently, leaving you with a useable machine. So there. :-) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 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
jimm@amiga.UUCP (Jim Mackraz) (10/24/88)
In article <7439@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: )In article <3037@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )>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. )> ) Oh, I get it. IPC can occur through any port I care to name, )including the IDCMP port if I so desire. And I won't get IPC messages )unless I register my port. Perhaps the original article should have been sub-titled: "How to use your IDCMP port for other things, or a port you created for IDCMP." ) I guess the reason I'm having difficulty understanding all this in )one pass is that I've had my own vision of an IPC system for some time, but )I guess I never imparted it correctly, because no one seemed to like it. ) ) My vision was that *every* program would respond to a defined set of )coded commands (read, write, stop, etc.). The idea was that all programs )would respond in the appropriate way when sent the command. This means that )you could write a script that did a generic thing, and apply it to all the )programs you had without modifying it. ) ) Since all programs would be doing this, and all programs obeyed the )same exact commands, Freeze it here, Eddie. I am all for common command sets, but we don't have them. Also, people are using IPC for things are beyond the reach of any common command set. I'm working here on a minor technical point of what the options are at the lowest application level. )connection would take place through the pr_MsgPort. To )send a command to a program, you'd look it up in Exec's list of running )tasks (checking to be sure it's a process first), and send it a command. It shouldn't matter too much where people receive universal commands. Using a port that happens to be around is sort of "registering a port by side-effect," and it isn't much more complicated to separate the "registration" from the "being a task." After all, while making a standard for IPC commands, you can certainly impose a standard place to find target ports for addressing the commands. For historical reasons and probably others, decoupling task/port is important because there isn't a 1:1 correspondence between pr_MsgPort and IPC participants. ) Well, *I* thought it was neat... The idea of sending standard IPC messages to applications as a matter of standard operating procedure IS neat. )>) 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). )> ) Oh, great. Does this mean Intuition uses some other method of )Signal()ing me when a message is ready? Intuition DOES NOT signal you. It sends you message. Exec signals you, initiates a software interrupt, or just AddTail's the message. For that matter, it COULD invoke the dreaded ACTION_3!! What THEN?? Just dig this bad vibes from exec/types.h: "#define mp_SoftInt mp_SigTask" )>) 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, ... )> ) I usually put it in for debugging reasons, and then never bother to )take it out since it's "never" going to get called anyway. It's helped *me* )out on a few occasions. And my die() routines are scientifically designed )to kill the program coherently, leaving you with a useable machine. )So there. :-) Leo Schwab, Software Assassin. I like it it. It has a good beat and you can dance to it. There are no plans to send IDCMP messages to a program which doesn't request them. Your approach should continue to work. What I put in my default case is: default: serout = fopen( "ser:", "w" ); fprintf( serout, "atdt14085553303\n"); fprintf( serout, "guru\nbloodlust\n"); fprintf( serout, "mail jimm\n"); fprintf( serout, "Someone sent me an unrecognized IDCMP message!!\n.\n"); fprintf( serout, "logout\n"); fprintf( serout, "ath\n"); Alert( AN_DOSNOMEMORY ); jimm )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.
jimm@amiga.UUCP (Jim Mackraz) (10/24/88)
In article <8810191748.AA01195@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
)> 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.
I think you're "reading beyond the lines" in my proposal. I'm not proposing
that the IDCMP become some standard address for interprocess messaging.
And I in no way endorse people sending actual IDCMP messages to a Window
unless you are Intuition.
) 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
I don't like the "standard port hanging off of my window." In Microsoft
Windows, messages are sent to windows, but in our world, it's just a
limitation. A Window isn't such a great standard application representative,
anyway.
Take Preferences, for example. Right now, how does a driver or something
hear about NEWPREFS? As another example, I've got programs running
with Commodities Exchange that pop open a window when a message arrives
at a port. No point in having that port be located by looking at
some window.
Ports is ports. You will be able to arrange with a new preferences to
get messages sent to a port of your choosing. Commodities sends messages
to ports you register with it. Looking up a port by name in the system
list is another form of registration that has nothing to do with
Windows.
It is easy to manage multiple ports registered with multiple services,
but arguably not as convenient to manage as a single port.
Also, if you wish to handle messages from various services in the
order they arrived, it is a lot more convenient to use a single port.
The proposal I've posted is about doing this general port sharing, especially
since one of the important existing IPC services has this existing data format
and the ugly tendency to delete the port when you tell it you don't want
any more messages.
There should be nothing special about Intuition as an IPC service,
especially the managing and registering of ports. Some standard example
code or perhaps functions in amiga.lib will perhaps be able to
focus application communication around Ports, rather than Windows.
Making standards for the IPC traffic itself would be the next problem.
jimm
--
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.page@swan.ulowell.edu (Bob Page) (10/25/88)
jimm@cloyd.UUCP (Jim Mackraz) wrote: . default: . serout = fopen( "ser:", "w" ); . fprintf( serout, "atdt14085553303\n"); . fprintf( serout, "guru\nbloodlust\n"); . fprintf( serout, "mail jimm\n"); . fprintf( serout, "Someone sent me an unrecognized IDCMP message!!\n.\n"); . fprintf( serout, "logout\n"); . fprintf( serout, "ath\n"); . Alert( AN_DOSNOMEMORY ); Make sure you fflush() that sucker before the Alert, eh jim? Nice descriptive alert message, too. Blame it on DOS whydontcha. Seesh. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/25/88)
In article <3051@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >In article <7439@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >) Since all programs would be doing this, and all programs obeyed the >)same exact commands, > >Freeze it here, Eddie. I am all for common command sets, but we don't have >them. I know. It was *merely* an idea, that's all. Nobody I told ever seemed to like it, so I guess it must have been a pretty lousy one. [ Actually, we do have a form of common command set: The commands sent to Exec devices. ] >) I usually put it in for debugging reasons, and then never bother to >)take it out since it's "never" going to get called anyway. It's helped *me* >)out on a few occasions. And my die() routines are scientifically designed >)to kill the program coherently, leaving you with a useable machine. >)So there. :-) > >Leo Schwab, Software Assassin. I like it it. It has a good beat and you >can dance to it. > This is something we'll have to talk about in person, since it appears to be an important point, but let me attempt to justify the maneuver: When you open a Window, you specify to Intuition what IDCMP events you wish to receive. I interpret that to mean that I will receive *only* those events that I asked for. If I receive something I didn't ask for, I want to know about it. Hence, the die() directive. If it helps you sleep better, I will make sure there are no such constructs in Onion. >What I put in my default case is: > > default: > serout = fopen( "ser:", "w" ); > fprintf( serout, "atdt14085553303\n"); > fprintf( serout, "guru\nbloodlust\n"); > fprintf( serout, "mail jimm\n"); > fprintf( serout, "Someone sent me an unrecognized IDCMP message!!\n.\n"); > fprintf( serout, "logout\n"); > fprintf( serout, "ath\n"); > Alert( AN_DOSNOMEMORY ); > Ah. You've read the source to Robotroff, I see..... :-) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 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
dale@boing.UUCP (Dale Luck) (10/25/88)
>jimm@cloyd.UUCP (Jim Mackraz) wrote: >. default: > So what happens when programs start getting middle mouse butten events when the used to only get left and right mouse button events? I can see there is going to be needed a seriously long beta test period. Dale -- Dale Luck Boing, Inc. {uunet!cbmvax|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:>jimm@cloyd.UUCP (Jim Mackraz) wrote: :>. default: :> : :So what happens when programs start getting middle mouse butten events :when the used to only get left and right mouse button events? :I can see there is going to be needed a seriously long beta test :period. :Dale DME will handle it! You can even map it... assuming intuition were to begin sending said events. Couldn't resist!, -Matt