Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-lcc!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: User Perception of IPC Operation
Summary: No problem.
Keywords: IPC, Object-Oriented, DPaint
Message-ID: <6402@well.UUCP>
Date: 28 Jun 88 20:52:21 GMT
References: <6393@well.UUCP>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Organization: The Blue Planet
Lines: 113


ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes about OOIPC vs. PPIPC:
	[why is the person's REAL name in _parenthesis_?]

| My primary objection was, "Who enumerates the methods?"

The programmers writing the servers, of course.

|         Under an OOIPC system, the paradigm is, "Please method my object."
| This is a perfectly wonderful and useful way of dealing with things.
| However, the user's perception of the way things are going to happen is that
| he'll say to the machine, "Please method my object," and his object will
| come back to him methoded.  By and large, he will not understand that
| running programs are required to method his objects, and that by methoding
| objects, the program's internal state may change.

Leo has raised a good point, and undoubtedly a good source of confusion.
In fact, this is _exactly_ how things are intended.  By design, all the
information required for an object is stored within the object itself.
Therefore, methods are just code that operates on the object.  Servers
do not require an internal state, since any state information is local
to the object.  The user's perception is correct -- it doesn't matter
who did the "methoding," the only thing affected should be his object. 

[DPaint as an OOIPC server could be asked to diddle an image...]
| ...DPaint happily takes the ILBM, hacks it, and returns it.  The user is 
| happy and returns to work in DPaint, and finds that his work session was 
| munged because DPaint had to toss it to method his object.

If this is the case then DPaint is a badly-behaved server.  In general,
because objects contain all state information, servers should be able to
service multiple objects at once independant of the server's internal
state.  Ideally, DPaint should just apply the requested algorithm to the
object's bitmap without needing to modify its own bitmap. 

The scenario above could occur, of course, if the programmer didn't 
understand this basic idea.  But this is the fault of the programmer, 
not the user.  The user was right in thinking that "methoding" his 
object should have no side affects.

|         This is why I continue to support a PPIPC system, where the paradigm
| is, "Program controls program."  By saying that, the user is immediately
| informed that programs are being manipulated in the system, and that his
| actions will affect their future behavior.

There can be cases where the object to be "methoded" IS a program, in
which case the OOIPC paradigm devolves into "Program controls program."
The object's internal state is just the internal state of the program,
thus providing the same type of explicit program control that PPIPC
does. 

|         Under a PPIPC system, the result of the DPaint scenario would be no
| different.  But the user would realize ahead of time that *he is sending
| commands to DPaint*, and that his actions could screw up the work session,
| since DPaint will have to *do* something to satisfy the requests.

It's just a question of who does the mental work.  Under PPIPC, the user 
does the work of keeping straight who gets changed by what when.  Under 
OOIPC, the programer does the work of getting the design straight when
he implements his program.  There are different views about which is
more appropriate, but I happen to believe that the user should have the
easiest job possible, even if it's a hassle for the programmer. 
(Of course, the IPC.library would be designed to make things easy for the
programmer, even if it's a hassle for the library programmer. :-)

|        A PPIPC system also gives the illusion of more control over what is
| going on.  A user understands that he is remotely controlling programs in
| the system, ...

I agree that the PPIPC system gives you a warmer feeling about being in
control, but I can imagine a lot of equally unpleasant scenarios using
PPIPC.  Imagine running a PPIPC equiped DPaint VI on a multi-user Amiga,
or an Amiga on a multi-user network.  DPaint has gone and created an
IPCPort called "DPaint-Control" that anyone on the Amiga or over the
network can send commands to.  If someone else has a bitmap they need
modified they will just go send commands to the public command port.  So
suddenly, without warning, the image you've been working on for hours
erases and some other image starts to be assembled by remote control.
What a bummer. 

This kind of problem could occur even on a single-user Amiga if two
programs want to use DPaint for different purposes at the same time. 
You could imagine getting all kinds of crazy results as DPaint mixes the
commands from both programs on the same picture. 

| [under PPIPC, the user] can specify *precisely* how a program will
| perform a specific action.  Under an OOIPC system, how an object is
| served is never clear, except to the guy who wrote the server.

Duhh, what?  How a server behaves depends on the author of the server
*no matter what* the IPC mechanism.  If the author didn't document how
his server responds to commands/method-requests the server is equally
useless in either scheme.   I don't see how either methodology would be
more or less clear independant of the programmer's documentation. 

|         To be fair, an OOIPC system is *exactly* what you want for a
| consumer-level machine, since the paradigm is so understandable and elegant.

I think so too.  I want it even as a programmer.  _Especially_ as a
programmer. 

| However, the "problems" outlined above should be addressed before any
| serious work on it starts.

"Serious work" will be likely to start soon.  Let me take this
opportunity to thank Jim Mackraz and Fred Fish.  With their help I have
a head start on creating a shared IPC.library.  From a guy who likes to
try to do everything himself, a humble thank you. 

| Leo L. Schwab -- The Guy in The Cape  ihnp4!pacbell -\
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(shf@Solar.Stanford.EDU)