Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: IPC - IPCMessage and Networks Message-ID: <5896@well.UUCP> Date: 7 May 88 01:37:57 GMT References: <5699@well.UUCP> <9131@agate.BERKELEY.EDU> <5819@well.UUCP> <5872@well.UUCP> <1929@sugar.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 110 Keywords: IPC, standard, network +--- Peter da Silva | In article <5872@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: | > Pete's "for instance" example of passing messages down a network is | > really the *only* purpose I can find for defining a standard such as | > this. | That's like saying "why define a standard for command line arguments?". | Because not all programs will have full capability. ... | ... how about a stripped down version to run in machines | with only half a Meg (god, how blaze' you get about RAM). How about The point about commandline arguments makes sense. I can see how you might want to define a complex protocol for something and then implement only the most useful part of it. The IPCMessage makes that kind of thing relatively easy. My (small) objection to it is that the way the format is defined a large part of the work involved rests on the shoulders of the _client_, which seems wrong. All the server has to do is ignore the parts of the message it doesn't understand. The client on the other hand has to examine the replied message carefully to see what the server ignored and what it understood. | ... That's the big deal | about IFF formats, for example. A program can take what it wants and can | use from the file (or in this case the message) and send the rest back I hope you don't want your message format hated as much as the IFF standard. ;-) In fact, IFF files turn out to be a bad analogy for these very same reasons -- the work gets done by the wrong participant. It's MUCH easier to write IFF files than to read them, the reverse of the way you would want it. | > ... how does a network | > server attach itself transparently into the IPC system? | The discussion really hasn't addressed how you initiate a conversation. Just | how you talk once you've been introduced. I think the next topic should be | just this... rather than more wrangling over message formats. Ok. | I think the object-oriented approach presented recently has quite a bit of | merit. | Have you any ideas? Since the object-oriented approach IS my idea, I certainly do have ideas. ;-) The difference between my o-o approach and the Exec "named message ports" approach is analogous to the difference between the Yellow Pages and the White Pages. Named message ports provide a one-to-one mapping between names and ports, where the names are just something that the programmer made up for their program. This is like the White Pages in that you have to know the specific name of the server you want to use. The object-oriented approach uses a many-to-one mapping between services and ports, where services are an abstract description of an operation that a server will perform. This is like the Yellow Pages in that you use the service you want performed to look up the message port. I can think of a couple of ways for a network server to wedge itself transparently into such a system right off the top of my head. The o-o approach needs more than what the IPCMessage provides, however, since it needs a standard for data exchange as well as messages. The data exchange standard are the "objects" in the scheme. [my example of a possible network problem and most of Peter's reply deleted for brevity.] | But how does it know which data's modified if it doesn't look at the bits? In my example, it knows by virtue of knowing in advance what the server is supposed to do. If the command returned success, the client doesn't bother to check bits because it knows what the server did. On a non-networked Amiga, this assumption works even though it is a "wrong" assumption. It only fails using certain network servers. Hypothetically. | > The general problem is that the IPCMessage is a "soft" standard. It's | > just a set of rules and nothing breaks if programmers violate the rules, | > except down the line when someone expected the rules to be followed. | | What other sort of standard would you define? Let's hear your suggestions. | -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter What I call a "hard" standard is one whose design is such that mistakes are less likely. Pipes, for example, are much more smoothly integrated into a networking situation, since the metaphore of a byte pipe is a closer match to what networks do than passing pointers. The filesystem can be patched at the DOS level to work on a network, so programs that communicate using the filespace will naturally work over a network with no (or very little) hastle. The network and the functionality of data transfer are transparent to each other (unless you're being really crufty) so the programmer doesn't have to worry about the two domains interacting in unexpected ways. I don't want to do my interprocess communication by pipe, however. A set of library routines for creating and dealing with messages would go a long way to helping matters. When programmers can't figure out what bits to set on their own, they can just call the supported library routine which is guarenteed to do the right thing. Also, care needs to be taken in designing the flag bits and the library routines to make things easy for the client programmer. At least that's how I would do it. Overall, I like the IPCMessage format. Even though I find there are things I can't do with it, it does have a simplicity that I find appealing. I'm trying to create a hybrid standard using the best parts of both the IPCMessage format and the object-oriented design I have been working on. I'll shout if I come up with anything brilliant. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)