Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: IPC
Message-ID: <7452@agate.BERKELEY.EDU>
Date: 7 Mar 88 07:14:52 GMT
References: <7335@agate.BERKELEY.EDU> <738@nuchat.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ( Pete Goodeve )
Organization: University of California, Berkeley
Lines: 21
Keywords: tools, IPC, InterProgram Communication

In article <738@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes:
>THe idea of a 4 character ID and a length byte sounds good. I'd like to
>suggest that a single byte mightn't be enough.
>
... Sorry... somebody didn't make it clear (me?).  Stuart's structure had
a long size value (which I think is too much);  I'm suggesting using the
standard mn_Length slot which is a UWORD.  It probably would be a mistake
to encourage messages longer than 64K!  (If absolutely necessary, the data
section of some types of messages could be pointers to public memory.)

>IFF might be a good starting point. Each message would be an IFF chunk
>containing an ID and the usual IFF data for that chunk type.
>
... I think that's overkill.  See my posting yesterday...

>I think FindPort should be good enough for simple stuff. More complex
>situations could be handled by virtual device drivers. Matt Dillon's

Yes, with proper safeguards -- again see posting "IPC (1):...".

						-- Pete --