Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!petro!swrinde!ut-sally!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!ames!decwrl!hplabs!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: <6416@well.UUCP>
Date: 30 Jun 88 22:57:34 GMT
References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6387@well.UUCP> <2213@sugar.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 101


| From: peter@sugar.UUCP (Peter da Silva)

[discussion of caching deleted]
| > 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:

struct Cache {
	struct Nod owner_node;
	struct Nod base_node;
	struct Server *server;
	long valid;
	long class,cmd;
}
/* Cache structure.  A cache contains a pointer to a server and validity 
 * flag.  Flag gets set to INVALID whenever anything in the class tree 
 * for this cache changes, so the server pointer will always be marked 
 * appropriately.  The cache is also associated with a task, so when the 
 * task closes the library, its caches are freed.
 */

As you can see, the Cache does contain a reference to the class and cmd 
(method) codes for this server.  You can also find these by following the 
Server pointer.  The function used to apply methods to objects is 
defined as:

	long Dispatch(object,cmd,cache)
		struct Object  *object;
		struct Command *cmd;
		struct Cache  **cache;

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.  Dispatch() can be called with cache=NULL, and 
if it is the server and port will be looked up in the service database.  
If there is a cache, the Dispatch() function checks its validity and if 
it's good, compares the cached class and cmd codes to those requested.
If they match, the cached service port is used immediately.  If not, the
correct service port is looked up in the database and stored in the
cache. 

Note that if caching is used and the object class and command code are
the same on each call to Dispatch(), which is often the case, then the
response is very good.  Note also that caching is optional, which is
consistent with the OOIPC design philosophy -- that is, that you make
requests in the form of methods to be applied to objects, not commands
sent to ports.  The fact that there are ports involved is deliberately
obscure. 

| > want to make your objects network transparent, implement a `SAVE' method
| > on them.  This allows specific objects to use their own compression
| ...
| > in-memory bitmap object could have the `SAVE' method write the bitmap
| > out as an IFF file.  Since this is something that is generally useful,
| Good idea.

Thanx.

| > My main point is that I cannot implement an object-oriented scheme under
| > PPIPC as I understand it (at least not efficiently -- a broker with a
| > search every time and four context switches doesn't make it), whereas I can
| > implement everything that can be done with PPIPC under OOIPC nearly as
| > efficiently.
| Well, the broker doesn't *have* to be a seperate program, any more than
| it does with OOIPC. Like I said, the high-level behaviour of messages is
| wide open.

Some of the issue is personal preference.  It's obvious that 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.  

| Tell you what, then. Implement a demo OOIPC system and let's play with
| it. Submit it to alt.sources.amiga...

Funny you should suggest that...  In fact, I'm writing such a beast
right now.  I've been thinking about the design so long that the actual
coding is going very fast.  Although the full-blown system is a little 
elaborate, there are reasonable places I can short-cut to get things
working quickly.  The real test, of course, is to build some demo
applications and see how it works. 

Side note: Is there any way to use SDB when writing a shared library?

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. 
:-)
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)