shf@well.UUCP (Stuart H. Ferguson) (04/14/88)
(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)
ralph@mit-atrp.UUCP (Ralph L. Vinciguerra) (04/14/88)
I've been reading about Object Oriented programming approaches for a while
now with great facination. To have IPC implmented that way would seem to
be a real step forward for the Amiga.
Could anyone recommend some information sources on Object Oriented Solutions
that we could check out to better understand how it could be used for IPC ?
It seems the main problem is that it cannot be understood by conventional
approaches to programming, and yet, it may be far better than what we
are doing now. This is the feeling I'm getting .... I've been reading
about smalltalk.... I can see Rexx version 200, with a smalltalk style
browser installed...
Ralph
P.S.: Leo, you had me rolling on the floor from that last message !
:-) ;-> :-P :-O :-} :-X :-) I can't wait !doug@eris (Doug Merritt) (04/15/88)
In article <5693@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: > >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 I agree 100% with all of your points; sounds like you know whereof you speak. (How refreshing!) Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug
jesup@pawl12.pawl.rpi.edu (Randell E. Jesup) (04/15/88)
In article <5693@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >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. I think this is a very nice idea, and with a good set of servers turns the amiga into a real nice object-oriented system. Sort of like a Super-ARexx. (I'm sure Arexx could be made to work well in such an envirion- ment also.) Now all we need to do is make Workbench a set of servers and a user- interface. Then it would be really object oriented, and could be extended at will! > Stuart Ferguson (shf@well.UUCP) > Action by HAVOC (shf@Solar.Stanford.EDU) Will you be at the Devcon? // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
shf@well.UUCP (Stuart H. Ferguson) (04/16/88)
>>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. > I think this is a very nice idea, and with a good set of servers >turns the amiga into a real nice object-oriented system. Sort of like >a Super-ARexx. (I'm sure Arexx could be made to work well in such an envirion- >ment also.) Yes, there are a couple of ways I can think of right off the top of my head to incorporate ARexx compatable programs into an object-oriented IPC standard. A quick and dirty way would be to have ARexx compatable programs run inside the main system as REXX class objects with the main ARexx program running as the object-class server. Programs using the standard (object-oriented) IPC would send commands to these REXX class objects (which are actually each a program with an ARexx interface) and the commands would be serviced by the ARexx program and passed on to the programs referenced by the objects. A better way would be to enhance the ARexx language to allow users to register the services of their programs and scripts directly into the global service tables. ARexx would then be a scripting language inside the object-oriented IPC scheme. Either way, the ARexx program would have to be modified. I have to argue, however, that an object-oriented IPC such as I'm proposing does not make the Amiga into a real object-oriented system. I've just borrowed some of the concepts and ignored others in order to make the idea work on the Amiga as it is today. Important concepts such as data-hiding, for example. Since objects may be implemented by several servers possibily written by several different authors, the object description must be public, and cannot be allowed to change radically from implementation to implementation. Class heirarchies will have to be done in a somewhat strange way as well for the same reasons. You also wouldn't want to write object-oriented programs using this scheme either, since the task-switching overhead would probably kill you. But for a number of medium to large sized programs chattering among themselves, the object-oriented approach gives them a simple, powerful common language to use which is abstract enough that anyone can break into the conversation, or can use parts of another system for something completely different. > Now all we need to do is make Workbench a set of servers and a user- >interface. Then it would be really object oriented, and could be extended >at will! An idea after my own heart! In fact, the whole IPC idea came about as a result of my design for a user-extensible Workbench. I know that my ideas are getting across when other people start to invent them on their own :-). Needless to say, I have plenty of ideas about how to fit this scheme into a new Workbench. > Will you be at the Devcon? No, probably not. I've already shot the travel budget this year. > // Randell Jesup Lunge Software Development > // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 > \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 > \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup >(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-) -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
peter@sugar.UUCP (Peter da Silva) (04/17/88)
Brainstorming on object-oriented IPC. Preliminary note: since ports are named with a text string, there's no need to restrict object classes to 4 character IDs. In article <5693@well.UUCP>, shf@well.UUCP writes: > (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. Perfectly true. I like the idea of making all this object-oriented. Could you make a more specific proposal... laying out how a given service can be accessed and what a service does if it gets a message it doesn't grok (it should pass it to a more general service, but what does that mean?) for example. > 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 Actually, make that class fe2z.text.window, which passes messages it doesn't understand to text.window, which passes them to window. If you try to open fe2z.text.window and fe2z isn't installed then it should fail or open text.window with some sort of status code indicating that the port sever couldn't satisfy the request. The messages themselves can be pete/peter packets... > The real beauty of the approach is that NO classes need be defined at > all in order for the standard to exist. Well, you need to define the "base" class that just returns "unknown message" to all requests. > (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." That's just what it is, isn't it? > (1.c) Broadcast, MIDI or "message bus:" For this the program just does whatever it wants with the message *and* passes it on. Eventually it reaches the "base" port and gets sent back as an unkown. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.