🚀 go-pugleaf

At the June 16th BADGE meeting, Pete Goodeve presented his (and Peter da
Silva's) proposed Interprocess Communication standard with an excellent
slide show and examples.  Well done, Peter. 

The best part was when he revealed that the slide show program he was
running was itself an example of IPC at work.  It consisted of three
separate programs (four, if you count the semi-working Joystick Reader
;-) all operating asynchronously and communicating with each other using
the proposed standard.  The Script Manager asks the ILBM Manager to
pre-load images into bitmaps in memory and free them up when the Script
Manager thinks they won't be needed again.  The Script Manager also
sends messages to the Display Manager to take a pre-loaded bitmap
structure and display it.  The Display Manager in turn sends messages to
the Script Manager when the user clicks the mouse to move forward or
backward in the presentation. 

Altogether it made for an interesting demonstration, but there was one
aspect of it which exemplifies a problem with the proposed standard
which I have mentioned before.  The problem is that IPCMessages do not
provide for standardized data formats.  They deal with standard
_message_ formats reasonably well, but data is handled very
incompletely.  Peter ran into this very problem himself in implementing
his slide show program(s) and kludged around it. 

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?

The correct answer would seem to be the ILBM Manager.  It is the expert 
on bitmaps, after all, so it should know what items would be needed.  
Also, it's the only process that knows how many bitplanes this image is 
supposed to have.  But if the bitmap is to be the reply to a message 
from the Script Manager, then it is the Script Manager that would be 
required to initialize all the item fields for the return value of the
request.  This is clearly wrong, since the Script Manager should not be
required to understand bitmaps.  Another part of the problem is that the
Script Manager sends this same bitmap to the Display Manager.  If the 
Script Manager is going to construct its own message to pass to the 
Display Manager, it will have to allocate the space for and copy the 
items associated with bitmaps from the ILBM Manager.  This means that 
the Script Manager has to grok bitmaps again.

Peter's solution was to have the ILBM Manager construct the message that
will be sent to the Display Manager, and return that _message_ to the
Script Manager.  The Script Manager then uses that message to control
the Display Manager without understanding much of its contents.  No
reflection on Peter's programming skills, but this is a kludge.  Not
only does it (probably) violate the IPCMessage design, it also makes the
ILBM Manager a solution to this specific problem, and not a general
purpose tool for reading bitmaps. 

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

Peter has done a great job so far in allowing others to contribute to 
his design project.  Keep it up.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)