Path: utzoo!mnetor!uunet!nuchat!peter
From: peter@nuchat.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: IPC (2): Message Broker
Message-ID: <754@nuchat.UUCP>
Date: 9 Mar 88 03:07:05 GMT
References: <7413@agate.BERKELEY.EDU>
Organization: Public Access - Houston, Tx
Lines: 42
Keywords: InterProgram Communication, broadcast messages

In article ... pete@violet.berkeley.edu ( Pete Goodeve ) writes:
> [about a real neat idea for a message broker]

Sounds like a much better idea than my port-server idea (which is what I now
realise my last message was). You volunteering to implement it? (half-smiley:
someone has to).

I'm not sure the imcremental editor idea is practical, but the idea of having
a "bus" for broadcast messages is a good one. If the server could be made
fast enough, you could even use it for MIDI.

Did I say a good one? The idea is great! Go for it.

For some purposes you still need a port server. It's a lot less overhead once
the connection is made, and it can do some of the same things. It could even
look the same to the user.

How about this idea? You have a server named "SMUS player" that you can
open a channel to and send messages like 'INST', 'TRAK', and 'CLOK'. You
want to play a song, you do this:

	FindPort("SERVER");
	Send('ADDS', "SMUS player", myport);
	WaitPort(ReplyPort);	/* this will tell the master you want to talk
				   and wait for the player to tell you you're
				   accepted. It will probably only allow one
				   slave at a time. */
	Send('INST', "guitar", guitar_sample);
	Send('TRAK', smus_track);
	Then you can either
		Send('CLOK', 0);	/* Play a beat */
	or
		Send('CLOK', 72);	/* Start playing at 72 BPM */

	Send('DELS');

I don't think this could be easily handles by the message broker, but then
I don't think I could do the stuff the message broker likes.
-- 
-- a clone of Peter (have you hugged your wolf today) da Silva  `-_-'
-- normally  ...!hoptoad!academ!uhnix1!sugar!peter                U
-- Disclaimer: These aren't mere opinions... these are *values*.