Path: utzoo!attcan!uunet!lll-winken!lll-lcc!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPCMessages -- A Prototype
Keywords: IPC, standard, BADGE
Message-ID: <6523@well.UUCP>
Date: 14 Jul 88 21:31:21 GMT
References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6467@well.UUCP> <2275@sugar.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 92


+--- From: peter@sugar.UUCP (Peter da Silva)
| > [the cmd argument is a]
| > pointer to a struct containing not only the method code, but any
| > arguments that method requires, since most commands are more than just a
| > single code.  
| OK. I got the impression this stuff was in the object. Silly me.

I guess the other Peter thought this as well.  OOIPC is not as different 
from PPIPC at this level than it might at first appear.
 
| > | [ object servers that aren't seperate processes ]
| > This is a *neat* idea.  [...] Got more details on what you're thinking 
| > of here, Peter? 
| Off the top of my head:
[top of the head details deleted...]

I sounds sort of sensible.  In fact, I'm revising the OOIPC design to
include some sort of priorities for servers since this seems more useful
than not.  It might be fairly easy to add different classes of servers,
i.e. message port servers, function servers, (other types?).  I'm a
little concerned about public memory considerations since this scheme
would seem to mix things up pretty seriously, but obviously this isn't a
real concern with current Amigas. 

 
[discussing message formats ...]
| [ Basically looks like a PPIPC message with an extra pair of fields: an
|   object and an alias ]
 
| Why pass the object in the call to Dispatch *and* in the command itself?

I debated this a little, and I still may go and do it another way.  
Right now you just do Dispatch (command, object, cache) and the first 
thing Dispatch() does is:

	command->object = object;

I was trying to make commands and objects distinct things, but perhaps 
that's not such a good idea since it's not strictly true.

| I'm also not sure about the purpose of the "alias". Could you be more 
| specific?

Sure.  Suppose you have a server with one service port and you want it 
to serve lots of diverse commands and methods.  You could do:

	RegisterService (port, OBJ1, MTH1, 0);
	RegisterService (port, OBJ1, MTH2, 0);
	RegisterService (port, OBJ2, MTH3, 0);

and so on.  This means that any of these types of requests could be 
posted to this same message port requiring the server to look into the
command code and object class fields in order to determine what it is
supposed to do.  But this was already done by the library when it looked
up the port in the first place.  Why do it twice?  Thus aliases.  In
order to make to lookup happen only once, the server can register a
specific alias to be associated with a given service applied to a given
port, as in: 

	RegisterService (port, OBJ1, MTH1, 0);	/* alias 0 */
	RegisterService (port, OBJ1, MTH2, 1);	/* alias 1 */
	RegisterService (port, OBJ2, MTH3, 2);	/* alias 2 */

and so on.  When the server gets a command on its service port, it only 
has to look at the alias code to determine the nature of the request.  
In the example above, alias value 0 is a request for method code 1 on
object class 1, value 1 is method 2, object 1 and so on.  Using 
sequential integers as above makes for efficient switch blocks, or you 
could just pass the function pointer itself as the alias and just do 
(*com->alias)(com), if you're a trusting soul.

| Otherwise, the structures are close enough for government work.

Intentionally.  I could have used vanilla PPIPC messages, but I have 
conceptual difficulties with all the flag bits and was trying to see if
I could do it with fewer. 

| > By allowing `data' to point to an object, most of the flag bits under 
| > PPIPC become unnecessary.  If something has a complex behavior, that can 
| > be encoded into its methods if it's an object.
| That's cool. Got to worry about server loops, though.

What do you mean by "server loop?"  If you mean that servers can't 
normally be called recursively, then yes, that's something to worry 
about.  I haven't really got a good answer for that one, except perhaps 
using software interrupt style service ports, or using your suggestion 
of functions for synchronous requests instead of messages.

| -- `-_-' Peter (have you hugged your wolf today?) da Silva.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)