Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!tness7!tness1!nuchat!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: <2139@sugar.UUCP>
Date: 18 Jun 88 15:29:44 GMT
References: <6306@well.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 74

Regarding Pete Goodeve's demo of IPCMessages... (wish I was there).

In article <6306@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> His Script Manager calls on the ILBM Manager to read an ILBM file and
> return a bitmap structure.  The Script Manager then passes this bitmap
> on to the Display Manager for display.  So far so good.  The problem is
> 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.

Now you only have three objects that need to be dealt with. Voila.

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

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.
The main point is that they be tagged (BMAP, CMAP, and VMOD on the one
hand, or IMAG on the other, where IMAG is a struct { struct bitmap *BMAP,
USHORT *CMAP, ULONG VMOD }. The reader program would fill in either of these
structures. When you're finished you can grok bitmaps yourself and free them,
or send the reader (or any other program that groks it) a destroy message.

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

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

> If 
> this were done, then the Script Manager could ask for a bitmap and get a 
> pointer to one without having to know anything about it.

No problem.

> It could then 
> pass this pointer on to a display program or anything else with the same 
> blissful ignorance of what it really points to.  Obviously the ILBM
> reader and the display program need to speak the same language about
> what a bitmap is, but this is as it should be, just as it should be that
> the script program need not know. 

Right. It just knows that there's an object called "IMAG" that it can read from
the reader and send to the displayer.

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

Which Peter? Or both?
-- 
-- `-_-' 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".