Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: User Perception of IPC Operation
Message-ID: <4137@cbmvax.UUCP>
Date: 29 Jun 88 01:47:20 GMT
References: <6393@well.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 57

In article <6393@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>	Well, I finally nailed down a another objection I have to the OOIPC
>system:  User perception of operation.
...
>	Suppose that Dan Silva decides to write a version of DPaint that
>advertises its services under an OOIPC system, allowing users to have their
>ILBM objects methoded by DPaint.  Later on, after a session in DPaint, he
>goes outside of DPaint, and decides to have an ILBM hacked in some way.
>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.

A DPaint that is currently got a work in progress (i.e. not just acting as
a OOIPC server) shouldn't destroy that work when it does "method" on the
"object"; it should either save it's state, or ask the user what to do with
the picture he was playing with.  Otherwise, it shouldn't advertise that
it's an ILBM server.  Do it right, or don't do it.

>	When you advertise the paradigm, "Please method my object," you are
>making the methoding step an anonymous black box.  You are not making it
>clear that the user is, in fact, manipulating programs to perform the
>desired operation on his objects.  This is why the user is surprised to find
>the DPaint "screwed up" his work session.

	If you advertise a method as a black box, it should be so.  The problem
is in the assumption of how DPaint will handle the method.

>	The obvious solution to the above scenario is to write DPaint as a
>client of an OOIPC server that manipulates ILBMs.  However, this may not be
>feasable, since such programs require optimum response from the system, and
>the task switch overhead and passing around of objects may slow performance
>down enough such that DPaint feels icky.

	No, the obvious (to me) solution is to save the user's state while
handling the method/object request, and then restore them.

>	Under a PPIPC system, the result of the DPaint scenario would be no
>different.

>	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, and that he can specify *precisely* how a program will perform a
>specific action.

	Precisely????  I dunno about that....

>	To be fair, an OOIPC system is *exactly* what you want for a
>consumer-level machine, since the paradigm is so understandable and elegant.
>However, the "problems" outlined above should be addressed before any
>serious work on it starts.

	Was that any help?  (I hope it was, I was trying to be constructive.)

>Leo L. Schwab -- The Guy in The Cape  ihnp4!pacbell -\

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup