peter@sugar.UUCP (Peter da Silva) (05/25/88)
Well, whatever standard is decided on there is one capability that should be added. That is, the ability to have a route established by an external program. This would allow you to set up a patch panel a-la SoundScape and give the user a visual icon/mouse-driven interface. IPC would become a tool for naive users, instead of a fancy capability for hacks. Considerations like this are why I have avoided discussing the port-level protocol until the messages have been figured out. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
pete@violet.berkeley.edu (Pete Goodeve) (05/30/88)
In <2057@sugar.UUCP> Peter da Silva writes: > Well, whatever standard is decided on there is one capability that should > be added. That is, the ability to have a route established by an external > program. This would allow you to set up a patch panel a-la SoundScape and > give the user a visual icon/mouse-driven interface. IPC would become a tool > for naive users, instead of a fancy capability for hacks. I think you're right [...someday I must try disagreeing with you -- just for fun (:-))]. Some kind of patch panel setup will be needed eventually. I don't see any real road blocks in the way of such a scheme using the IPCPort protocol, though. I envisage that we'll reserve an IPCPort named "Patch_Panel". Each "conforming" process will send a message (maybe messages) there as it starts up, giving details of the services it can perform and it's own possible needs for services. Included will be gadget images for the patch panel to display. I assume a process could be started in a number of ways: from a startup script, from an icon, or even from the patch panel itself if this was primed with a list of candidate processes. The tough part is going to be deciding exactly how the patch panel itself is going to handle the various process types. Obviously you can't just connect any process to any other: clients will need particular services. Okay, I know servers will reject messages they don't understand, but I think that somehow the patch panel has to provide a guide, too. In my initial experiments, I seem to end up with three basic types of processes: "Clients", that only send messsages to ask for services from other tasks, "Servers" that accept those messsages, and "Managers" that both receive messages from some tasks and send them to others. These may all need different representations on the patch panel. A client (or manager) might need several servers for different functions, and the panel would somehow have to recognize which client "channel" was to be connected to which server. I guess all I'm really saying is that the foundations should be adequate for our needs. I think we can start implementing IPC stuff now; I've found simple startup scripts with a few command arguments (naming ports clients are to use and so on) enough to get things going, and a little experience with that will give us some better ideas as to what a patch panel needs. > > Considerations like this are why I have avoided discussing the port-level > protocol until the messages have been figured out. But don't you think that the IPCPort stuff is a good basis for any of the schemes we might want to try? I'm always fond of "Experimental Programming" for any reasonably complex project, rather than trying to design down to the last detail in advance, and my feeling is that Patch Panels, Object-Oriented-Communication, and the like, are all going to need lots of experimentation... -- Pete --