craig@unicus.UUCP (Craig D. Hubley) (03/26/88)
In article <5644@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >peter@nuchat.UUCP (Peter da Silva) wrote: >>How about, when you register a port, providing an icon for it... and having >>the icon show up in a SoundScape-like patch panel? > > [general praise for the idea and a good CLI line interface to match it] > >But this is user-interface stuff, and should probably be dealt with later. > >..Bob Urk. 80 lashes with a wet noodle, Bob. :-) Think about it. You're designing a system that is *nothing but* an interface: From programmers to other programmers From users (via CLI and WB) to their cooperating programs From brokers to their users and suppliers Now, what should be dealt with later ? The interface, or the nitty-grit. Last week I brought up the IPC concept at the Toronto ADF (Amiga Developers' Forum) meeting, and the response I got was: You mean I can get the system to [blank] my [blank] ? That's exactly what I need! From programmers and users alike. Not one person has ever said: You mean that I can expect to find ports with a standardized name whose behaviour I can predict and build programs around ? Thank God. In this case, programmers have more in common with users than not. Your own suggestion of a CLI line to set up a one-way connection is an example. I'm not suggesting the interface be frozen this way, just that right answers pop up easier when considering where the system will be used, not how it will be built. A good example from this debate was the question of whether to use IOStdRequests or not. People argued for many K over whether they needed its capabilities or not. This is too abstract for this level. We should be compiling a list of `things we can do with an IPC'. The SoundScape-style control panel is one. Bob's CLI equivalent is another. A fully automated message broker is a third. These are all controllers. What about users ? We have the examples of editing and displaying and printing IFF forms, what else is there ? I hereby volunteer to keep a list of potential uses of an IPC and to post it periodically. This should give us a better idea of what to include, than simply arguing over it. Anyone who's contributed so far probably has an idea, so send it in. Once *we've* done that, the newsgroup at large, which has long since abandoned us, I suspect, can see that we're thinking about them and add their own. Then we'll have something to design for. Come on, folks, flood my mailbox with IPC applications. Oh, please use the `dumb' addresses below and *don't* directly reply to this message, as some of our intermediate sites carry too much of our mail as is. Thanks, Craig Hubley, Unicus Corporation, Toronto, Ont. {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)