Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!tness1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: IPC - Generality, etc.
Keywords: Object-Oriented, IPC, Standard, yeahbut
Message-ID: <1853@sugar.UUCP>
Date: 17 Apr 88 02:56:30 GMT
References: <5693@well.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 51

Brainstorming on object-oriented IPC.

Preliminary note: since ports are named with a text string, there's no need
to restrict object classes to 4 character IDs.

In article <5693@well.UUCP>, shf@well.UUCP writes:
> (2) "You can't figure out all the object classes and messages in
> advance.  There would always be a case you didn't think of." 
> 
> This is true, and this is one of the reasons that the object-oriented 
> approach WILL work, not an argument against it.

Perfectly true. I like the idea of making all this object-oriented. Could you
make a more specific proposal... laying out how a given service can be
accessed and what a service does if it gets a message it doesn't grok (it
should pass it to a more general service, but what does that mean?) for
example.

> servers installed in the system.  So, if you're writing a program which
> uses IPC and need to define the new and bizarre object class `FE2Z', all
> you have to do is write a server for it.  While your server is

Actually, make that class fe2z.text.window, which passes messages it doesn't
understand to text.window, which passes them to window. If you try to open
fe2z.text.window and fe2z isn't installed then it should fail or open
text.window with some sort of status code indicating that the port sever
couldn't satisfy the request.

The messages themselves can be pete/peter packets...

> The real beauty of the approach is that NO classes need be defined at
> all in order for the standard to exist.

Well, you need to define the "base" class that just returns "unknown message"
to all requests.

> (1) "The object-oriented approach is a nice idea, but it's too
> specialized.  It should be built on top of a more general IPC
> methodology, one which doesn't assume anything about the type of
> messages that would be passed."

That's just what it is, isn't it?

> (1.c) Broadcast, MIDI or "message bus:"

For this the program just does whatever it wants with the message *and* passes
it on. Eventually it reaches the "base" port and gets sent back as an unkown.
-- 
-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These aren't mere opinions, these are *values*.