Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga Subject: IPC - Generality, etc. Message-ID: <5693@well.UUCP> Date: 14 Apr 88 08:41:40 GMT Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 101 Keywords: Object-Oriented, IPC, Standard, yeahbut Summary: Object-Oriented IPC is General (The debate rages on -- interesting this network conference thing -- more of a carnival than a conference. I just thought I'd step in once more and defend the child of my brain...) IPC - Generality How General is the Object-Oriented Approach? I've heard two complaints about my proposal for an object-oriented IPC standard that seem indicative of a basic misunderstanding of the approach. The complaints are, (1) it's not general enough, and (2) you couldn't figure out in advance all the object classes that might ever be needed. Let me answer them in reverse order: (2) "You can't figure out all the object classes and messages in advance. There would always be a case you didn't think of." This is true, and this is one of the reasons that the object-oriented approach WILL work, not an argument against it. The set of object classes and the commands they respond to is determined exactly by the servers installed in the system. So, if you're writing a program which uses IPC and need to define the new and bizarre object class `FE2Z', all you have to do is write a server for it. While your server is installed, that object class exists. When you remove the server, the class ceases to exist. If you need to add a new command to an existing object class, just write a server for that one command message, and use the old server for all the other messages. The real beauty of the approach is that NO classes need be defined at all in order for the standard to exist. Users can install or not install servers as they please to customize their environment. Developers will implement objects as the need arises, and as more object classes become generally available, developers will stop implementing new classes and start to use existing ones. The creation of object classes can be an evolutionary process where classes compete and the "fittest" survive. Although there are bound to be problems with this approach, I find it much preferable to the "classes pre-determined by committee" approach. (1) "The object-oriented approach is a nice idea, but it's too specialized. It should be built on top of a more general IPC methodology, one which doesn't assume anything about the type of messages that would be passed." First of all, it *is* built on top of a more general message passing scheme -- the message passing methodology built into the Amiga Exec. The point is to develop a system that integrates the environment. The object-oriented approach I think does that. In addition, the approach is so general that all other proposed methods are subsets. To wit: (1.a) Pipes: A pipe can just be an object, and any program or tool that uses pipes as a data channel can just be defined as a method on a pipe. So, for example, you could create a pipe and send it the `GREP' command (with arguments, obviously). The pipe would envoke the `GREP' method on itself by passing Exec messages to a grep program behind the users back. The return value of the `GREP' method could be another pipe object. (1.b) "Program controls program:" An object can be any specific instance of a general class, *including a process.* If you want to control a specific program, just create an object of class "Process" which is that program and send commands to that object in the standard way. Presto! -- your program controls another program directly using a special command protocol if you want, and you do it in a standard way without having to muck with those messy message ports yourself. (1.c) Broadcast, MIDI or "message bus:" This is a little trickier, but then the whole idea is kind of odd. The basic idea is that there is some source of "broadcast" messages, such as a MIDI source or a lab experiment, and there may be several processes doing stuff to the data or it may just dissapear into oblivion, and this fact is irrelevant to the source of the data. Such a scheme could be mediated by a meta-object like a "message bus." The source of the data could create an instance of an `MBUS' object and programs which want the data could find that message bus and attach themselves to it. When the source program sends messages to the message bus, the message bus server could then dispatch copies to the attached processes, or send the message from process to process bucket-brigade (MIDI) style. How messages were handled would be up to the person impementing the message bus server, not the designer of the IPC system. I hope that this clears up some of the confusion about the object-oriented approach I'm pushing for. It's not a single-minded and specific idea, but rather it is a very general model which provides a wide range of interpretations and uses. The object-oriented approach will require different kinds of implementations than other methods, but it is at least as general, if not more general, than anything else proposed so far. Hopefully these examples have provided some insight into how I imagine an object-oriented IPC being utilized. Obviously the best way to demonstrate these concepts is with working code, but that takes time. If you want a simple standard, just use named message ports, since that's a standard available to all. If you want something more sophisticated, try to understand what I'm suggesting. I think it will work, and work well, and I have yet to hear any objection that makes me question that. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)