Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!teknowledge-vaxc!sri-unix!joyce!mordor!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: <6338@well.UUCP>
Date: 21 Jun 88 01:33:17 GMT
References: <6306@well.UUCP> <2139@sugar.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 87


+--- From: peter@sugar.UUCP (Peter da Silva)
| Regarding Pete Goodeve's demo of IPCMessages... (wish I was there).- 
| In article <6306@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
...
| > that a bitmap can consist of several different chunks of memory: the 
| > bitmap structure itself, a color map, up to six bitplanes and possibly 
| > other stuff.  Because of the way the IPCMessage is designed, each of
| > these requires its own IPCItem entry.  The question then becomes: Who 
| > creates those IPCItems?
| Well, there are really only three peices of information you need: the
| bitmap (BMAP), the color map (CMAP), and the display modes. The struct
| bitmap contains all the bitplanes.

Therein lies the problem.  See below.

| > In prototyping the system, Peter has uncovered what I believe to be a 
| > major drawback of the IPCMessage design.  A solution to this problem is 
| > to implement a standard for abstract data objects, such as bitmaps.
| If you look at my original proposal, you would have seen at least one
| such data object: a file. The format for a file structure was a lock
| on the directory the file was in, and the name of the file in that
| directory.

Sorry, I didn't remember that from your early postings on the subject.
My understanding was that when passing memory between programs with an
IPCMessage, each continious block of memory needs its own IPC item.  That
constraint, as I recall, is required to allow IPCMessages to be passed
over a network.  I may have missed something, but isn't that what the
IPC_NETWORK and IPC_INMESSAGE flag bits are about as well? 

| There is nothing that says that the primitive structures the IPC items
| point to can't be defined at a higher level than Amiga native structures.

Having IPC item pointers that point to structures containing pointers is
what Pete Goodeve called, "the royal road to chaos," in his response to
a message of mine.  If you take out the pesky network limitations then
you can have pointers to pointers all over the place -- it just won't
work over a network. 

| I still think that a better high-level protocol for this stuff is necessary.
| Stuart Ferguson's own object oriented stuff is a good start. It just needs
| tagged structures, I think (and I could be all wet about that). Here the 
| reader and the displayer TOGETHER should somewhere have a name. The reader 
| tells the object server that it knows about the IMAG/READ and IMAG/KILL 
| pairs.  The displayer knows about the IMAG/SHOW and maybe IMAG/EDIT pairs...

| Then the master program asks the object server for a program that knows
| about each of IMAG/SHOW, IMAG/KILL, and IMAG/READ. It gets three message
| ports (one repeated). Voila. When finished it replies to the IPCMessages
| it got from the object server, and the server tells the programs they can
| exit if they like...

This is a reasonably good summary of the concept.  Implementational 
details are different the way I imagine them, but this is the basic 
idea.

| And of course the object server talks in IPCMessages...

Perhaps.  My design doesn't quite jive with some of the basic
assumptions of the IPCMessage and IPCPort design.  For example, the
ports need to be kept in a private list and not made available to
clients directly.  By keeping ports insulated from client tasks, the
port for a given service (such as "IMAG/SHOW" in Peter's example) can
change on the fly without the server knowing it.  Also, since clients
are not posting to ports directly, the ports are "safe."  This is a
completely different concept than the IPCPort "reference count" idea. 
There are other significant clashes that would need to be ironed out in
order to implement one under the other. 

When I get some free time (hah!) I'll try doing just what Pete Goodeve 
did and prototype my idea.  There's nothing quite so persuasive as 
working code.  (On that note, the Arexx demo the same night was also
really impressive.  Makes one realize the true (rather than
hypothetical) power of multitasking with an integrated environment.) 

| > Peter has done a great job so far in allowing others to contribute to 
| > his design project.  Keep it up.
| Which Peter? Or both?

My apologies.  Of course I meant Peters, plural. :-)

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