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)