[unios] IPC in the current OO model

OJ Hickman hickman1@peak.org
Mon, 21 Dec 1998 21:32:37 -0800


From: OJ Hickman <hickman1@peak.org>

IPC in the current OO model.
By Omer James Hickman - December 21, 1998

As I understand the current OO model each object has a set
of methods that are accessed over the IPC channels. Correct?

Since you can't have direct calls between objects with
different states they must use the IPC infrastructure to do
interobject invocations.

I can only come up with two ways of doing this:


1: Interpret method tokens.

Each message would be of the form of:
----------------------
Token      - First byte or word in the message
.
.
.
Parameters and data
.
.
.
----------------------

The receiving object would have to test the token with
conditional logic and redispatch the call. About the same
mechanism as old time BASIC interiptors.

Example code:
----------------------
/* Server code */

msg = msg_get(port);

switch (msg.token)
{
case METHOD_TOKEN_1:
	method1();
	break;
case METHOD_TOKEN_2:
	method2();
	break;
.
.
.
}
---------------------


2: Setup a communication channel for each and every method.
This would involve a system with thousands of open
communication channels. The overhead would be monstrous!



If someone can come up with another solution, do tell!



Solution #1, which seems to be implied by the current model,
is like sending a letter by putting each word on a separate
post card. The postage cost would really add up! IPC is done
with expensive calls to higher protection levels, it too
would add up.

Batching invocations, one of the main points of LOS, would
mean multiple inexpensive iterations of the token decoder
loop for each expensive call to the IPC system.


The OO type inheritance system of Vocabularies and Jargons I
outlined would provide a structured framework to define the
reprensations of methods, that is, tokens.

For example:

Object X is a console.
Object Y is a storage system.
Object Z is a user program using A and B.

Both X and Y have some common methods such as READ and
WRITE. Are these going to be represented by different tokens
sent to X and Y? I don't think so.

However, X and Y need to extend their interfaces in a
derivative way to add operations such as CURSOR_LOCATE to
the console and OPEN_FILE to the storage system.

Object Z only needs to know the root vocabulary plus the
jargonal extensions made by X and Y. This does reduce
duplication of definitions.
_______________________________________

Note: I do admit that LOS is a form of OO, or more
accurately an extenuation to the classic model of objects.




Omer James Hickman - hickman1@peak.org - ojh@hotmail.com
http://members.tripod.com/~OJ_Hickman

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios