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)