Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!killer!tness7!tness1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPCMessages -- A Prototype
Keywords: IPC, standard, BADGE
Message-ID: <2237@sugar.UUCP>
Date: 2 Jul 88 13:19:19 GMT
References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6416@well.UUCP>
Sender: news@sugar.UUCP
Organization: Sugar Land UNIX - Houston, TX
Lines: 73

In article <6416@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> | From: peter@sugar.UUCP (Peter da Silva)
> | > Second, caching makes list searching a rare event.  A cache is just a
> | > pointer to a port plus a flag to indicate if the cache is still valid.

> | How about adding one more thing to a cache: the object and method it's
> | a cache on. That way you can use the cache as an "opened" port, and
> | not have to deal with the rest of the info again. That makes it a lot
> | less obtrusive.

> It's actually like that already; I just didn't specify that before.  The
> cache structure I'm using as a strawman is as follows:

Good. Now then...

> 	long Dispatch(object,cmd,cache)

Might I make a suggestion. First, once the cache is set up, allow this:

	lresult = Dispatch(object, 0, cache)

If the cache is invalidated, it still contains the class and command, no?
This cuts down the baggage you need to carry around. I guess this could
be a macro, but then the user needs to look at the cache internals, which
is probably not a good idea.

Finally, have a call to set up the cache ahead of time:

	lresult = InitCache(class,cmd,cache)

This way, the cache can be though of as an opened port to the class and
command. Also, this lets you do the "slow" location of the port outside the
realtime loop.

> The Object and Command structs contain the class and cmd (method) codes, 
> respectively, for this request.  Note that the combination of object and 
> command uniquely define the server to be used, so no port actually need 
> be referenced explictly.

Also, as noted above, the combination of object and cache also uniquely define
the server to be used.

> The fact that there are ports involved is deliberately obscure. 

Even if you use the cache in the way I described, it doesn't have to look like
a port. In fact, now that I think of it, you don't necessarily even need to
use messages and ports.

This way the OOIPC stuff can have varying implementations: all OO, but maybe
not all IPC. You could even have (say) an ILBM library that you register as the
default ILBM server, so that the Dispatch function actually makes library
calls instead of sending messages... you get all the flexibility of IPC, and
maybe even higher preformance.

> [Some] programmers are going to want an IPC mechanism more like PPIPC and some
> are going to want OOIPC.  It's silly to restrict people to using only
> one paradigm.  There may be a way to integrate the two approaches and
> get the best of both worlds in terms of performance and features.  

Complete agreement. Which is why I encourage you to use PPIPC messages...

> Curiously enough, I found that my original spec for standard messages
> and objects may not be sufficient, and the result of the redesign is
> starting to look a little like IPCMessages.  Highly simplified, with
> only 2 flag bits instead of 7 or 8, but its ancestry is clearly evident. 
> :-)

Well, would it be possible to bring the actual message formats closer? What
do you need that PPIPC messages don't provide?
-- 
-- `-_-' Peter (have you hugged your wolf today?) da Silva.
--   U   Mail to ...!uunet!sugar!peter, flames to /dev/null.
-- "Running DOS on a '386 is like driving an Indy car to the Stop-N-Go"