shf@well.UUCP (Stuart H. Ferguson) (06/29/88)
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)
peter@sugar.UUCP (06/29/88)
In article <6393@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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. Programs that method an object shouldn't method anyone else's objects. If an author did this, then he would be wrong. If it turns out that DPaint *does* need the space, it should tell the user that there's not enough memory, and ask if he would like to toss his work session. > 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. Not to mention that he gets to hook up the Butcher icon to the dPaint icon in his IPC Patch Panel... which gives a great visual feedback. I must admit that one reason that I prefer PPIPC over OOIPC (apart from the fact that PP > OO :->) is that I *want* to wire my software up like this. > 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. No, it should be started as soon as possible. I think Stuart should get down to writing code so we can have some facts. It's so much more satisfying to flame when you have some real facts. -- -- `-_-' 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".
jesup@cbmvax.UUCP (Randell Jesup) (06/29/88)
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