Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu ( Pete Goodeve ) Newsgroups: comp.sys.amiga Subject: Re: IPC - A proposal Message-ID: <7419@agate.BERKELEY.EDU> Date: 6 Mar 88 11:27:06 GMT Sender: usenet@agate.BERKELEY.EDU Reply-To: pete@violet.berkeley.edu () Organization: University of California, Berkeley Lines: 169 Yeah...! The race is on...! =============================================== shf@well.UUCP (Stuart H. Ferguson): > Ok, ok. Enough hype. You get the idea that I'm really excited by the idea? > Good. I am. Here's a first cut at it ... > > IPC1 - Interprocess Communication Standard (Proposal) > =============================================== dillon@CORY.BERKELEY.EDU (Matt Dillon) > This is what I envision: > ..... > > I could work on something like this after I get DNET out. > =============================================== ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) > I had hoped this controversy would have stayed quiet until I could > have thought of an elegant mechanism for this. I have the beginnings of it, > but it's not at all completely worked out. > > Gimme some time; I'll try and cook something up. Who knows? It may > actually be worth something. =============================================== That's odd, Leo -- those have been exactly MY feelings for the past two years... And I thought *I* was going to be the one to do it... Anyhow, when Ron Minnich finally brought the subject up, I thought it was about time to get on with it. As I expected, though, each of us is focussing on a different part of the problem (which is an excellent thing, naturally). Stuart and I are more concerned (at the moment anyway) with basic message protocols, while Leo on the other hand says: > Stuart was trying to address data exchange. This is only a minor > part of the whole problem. I disagree. It's the MOST important thing to get right FIRST. I do agree that it shouldn't be very hard, and that there are lots of fascinating avenues to explore in the area of command scripts immediately afterward. I'll stress again, though, that messages are NOT necessarily command lines. See my current posting "IPC (2)..." for examples of the other sort. > ..... The format of the data should be the problem of > the program asking for it (this is how it is currently). ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Exactly. And exactly the problem at the moment. If we are to have our network of interacting small modules, each MUST be able to understand what others are saying, without having to write special cases for them all. > Data format exchange standards should not be worried about just yet. > We have to establish a method of communication and "remote control" first. We seem to disagree again... Try it the other way around. > If Sculpt and VideoScape had remote control ports, the John Foust's > Interchange program could be nothing more than an ARexx script. Dunh Hunh? How do you figure that? --------------- OK...now turning to rip Matt to shreds...(:-)) Actually, aside from the fact that Matt has again focussed on the building rather than the foundations, I don't have much criticism of his suggestions. > But we don't simply want a stream oriented IPC. People don't take enough > time to think of easy ways to provide maximum power and capability. So right. And I think that first sentence is a key point: streams work well a lot of the time, but not always. Messages will always arrive sequentially ('least until we get a truly parallel Amiga), but they should be able to give us full random access of any object -- a paragraph from a text file, a chunk out of a picture, or whatever. > -Symbolic Asynchronous Remote-Control capability (domain based) > e.g. one application can send symbolic commands to another... > A data stream, as part of a command, would be a minor item in > this system. Could you expand on this please, Matt? I assume by "Symbolic" you don't necessarily mean ASCII. And the existence and format of the (binary?) data would be determined by the command. If so, this isn't very different in concept from a standard message format, where the ID -- and possibly subsequent codes -- determines the "command". > Also, have a standard format for SARC menu item simulation. ^^^^ This acronym seems to have slipped by me. Can you translate, please? My general comment on both Matt's and Leo's proposals is that the script handler, macro handler, or whatever you want to call it, should be just another module among the set that a user can hang together under a universal IPC structure. Matt should write one according to his philosophy, and Leo should write his, but a user should be able to pick the one he likes and plug it in with the rest of his favorites. He could even use ARexx if it suited him and obeyed the common message rules. This is pretty much the way it is at the moment with command shells: some people like my Sili(Con:), others like Matt's shell, and there are lots of other possibilities that all work (mostly!) within the same environment, but have different philosophies that suit different people. And that's healthy. --------------- Finally, I'd like to disagree with Stuart a bit too. (Controversy is fun, isn't it!) > This describes the format for a standard message block. ..... > ..... > ....... The basic design is derived from the EA > IFF 85 standard, since that has worked so well and lots of Amiga users ^^^ I think that requiring an IFF type format for all messages is overkill (though I don't share Leo's disdain for the format -- it certainly should be an available option). > struct GenericMessage { > struct Message gm_mess; > ID magic_code; > long gm_size; > ID gm_code; > char gm_body [ /* value of gm_size - 4 */ ]; > } If you compare this with my suggested structure ("IFF (1): Ports & Messages") you'll see that I favor a rather simpler one. I don't really think a "magic code" is needed, because I can't envisage any situation where a "rogue" message would arrive at a port; only applications that knew about the protocol would exist in the shared environment. Also the gm_size slot is superfluous, because there's already a mn_length slot in the message structure. From that point on, our concepts of "code" and "data body" pretty much mesh -- except as I said, I don't think we need to enforce an IFF type structure on the basic message. The structure of the data should be defined only and exactly by the message code. If the code happens to be "FORM" or "LIST" or "CAT", then it IS an IFF (complete with following size word and subsidiary chunks), but a "TEXT" type for example would just be a null-terminated string of characters. I've tried to address some of the other issues that Stuart raises -- communication model and so on -- in my other postings. I'll see what scorn is heaped upon them before I go further in that line. > Also, just hashing out a good idea won't make it a standard. It will > require some software that uses it, as well as some cooperation from the > software people at Commodore. Any ideas about how to go about the "public > relations" part of the standards design? Once again... Right! So how about it CATS? > > All too often we get stuck with short-sighted or limiting "de-facto" > standards more or less by accident (the IBM PC is a good example). Let's > not let this happen this time. Thanx for the bandwidth. We're off to a good start, folks. Let's keep hashing a little while, though, and see if we can raise most of the snags BEFORE we implement. Then we might just end up with something really great! -- Pete --