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: <5925@well.UUCP> Date: 10 May 88 22:32:55 GMT References: <5699@well.UUCP> <9131@agate.BERKELEY.EDU> <5819@well.UUCP> <5896@well.UUCP> <1948@sugar.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 62 Keywords: IPC, standard, network +--- Peter da Silva writes: | In article <5896@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: | > 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. | I don't see a way around this. Have you an alternative? Yes, but you may not like it. I would require that the server reply with an error if it failed to understand ANY part of the message. Clients would then be guarenteed to get what they asked for or nothing at all. The message format could provide status flags for optional arguments, but the client would have control over which arguments were optional, not the server, so the client only has to check the "understood" bit for items that it marked as "optional." This puts the work on the server side which is where I would want it. I could imagine a case where a client requests that a bitmap be modified in a certain way, and the server only understands half the arguments and does irreperable damage to the bitmap. The idea above would prevent this kind of misunderstanding. | > I hope you don't want your message format hated as much as the IFF | > standard. ;-) | I *like* the IFF standard. I don't know why people are turned off by it. | The only thing that's obscure about IFF is the recursive stuff is a pain, Despite my comment, I actually do like the IFF standard, and I agree that it's a reasonable compromise given the problems with devising any standard. It's just that I've met alot of people who curse the IFF format and the code EA provided for it. I conclude that it's not the format that people hate, but rather the fact that there's no good, generally available tools for reading and writing it. An IFF.library would do a great deal towards inproving the IFF format's P.R. problem. | > 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. | From my reading I got the impression that servers were the objects, and the | o-o stuff was mainly intended to get the right guys talking... with the | added advantage that you could do a "sendsuper" to your parent for messages | you didn't grok. No, the situation you describe where the server itself is the object is a degenerate case which can be used to get the more familiar "program controls program" communication metaphore using the object-oriented approach. In general, objects are data structures describing the target for the command in a message. For example, if someone defined a bitmap-class object, then this class of object could be operated on by many different servers. This results in a greater unification and uniformity of tools (theoretically). In the degenerate case, the server declares itself to operate on a "dummy" class of object which just allows clients to find its message port(s). The class heirarchy would also be implemented by the IPC.library, at least the way I imagine it, so it would be transparent to both clients and servers. | -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)