Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!ll-xn!ames!killer!tness7!tness1!sugar!peter
From: peter@sugar.UUCP
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPCMessages -- A Prototype
Keywords: IPC, standard, BADGE
Message-ID: <2213@sugar.UUCP>
Date: 28 Jun 88 21:38:09 GMT
References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6387@well.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 50

In article <6387@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> | My objection to this is speed. I can send a message to a destination port
> | and get the response back in two context switches. I don't have to search
> | any lists, private or otherwise. You paid some slight attention to this
> | problem with your caching setup. But the cache is obtrusive, and doesn't
> | behave in a predictable way.

> I'm pleased to see that Peter read my preliminary design spec.

I try to avoid commenting on stuff without reading it, even if I'm not
always successful :->.

> 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.

> If you think of a cache as just a pointer to a port, it's no more
> obtrusive than having an explicit pointer.

Except that now you have two names for the port that you have to pass
around... see above.

> 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.

> 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.

Tell you what, then. Implement a demo OOIPC system and let's play with
it. Submit it to alt.sources.amiga...
-- 
-- `-_-' Peter (have you hugged your wolf today?) da Silva.
--   U   Mail to ...!uunet!sugar!peter, flames to /dev/null.
-- "A foolish consistancy is the hobgoblin of little minds".