Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!tness7!tness1!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Object Oriented IPC -- Some reservations
Summary: Poking my fingers into the pie.
Message-ID: <2313@sugar.UUCP>
Date: 15 Jul 88 17:50:42 GMT
References: <11750@agate.BERKELEY.EDU> <6524@well.UUCP>
Organization: Sugar Land UNIX - Houston, TX
Lines: 45

... and stirring up trouble ...

In article <6524@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> Probably calling it IPC is a mistake.  It should probably be called
> something else. 

How about OO-OSE, object oriented operating system extensions.

(then my idea for procedural subsets would be local OO/OSE, and seperate
 servers are a global OO/OSE...)

> In the example given of the FILE - IFF - ILBM class hierarchy, you 
> probably wouldn't want to override the reading method when creating each 
> subclass.  You might want to read and IFF as if it were a FILE for 
> example, so you could call the different methods FILE/READ, IFF/RIFF, 
> and ILBM/RDBM.  This would allow you to READ an ILBM as if it were a 
> file, RIFF it as if it were an IFF, or RDBM it like a bitmap.

I don't like this idea. Better to set up different objects of the
appropriate type. Why would you want to do a FILE/READ on an object
of type ILBM? There isn't any meaningful place to read into.

> | I get the feeling that we're reaching a consensus that BOTH PPIPC and
> | OOIPC will have their place...

> I doesn't make sense to have TWO "standards."  Either paradigm could be 
> implemented as a sub-set of the other, it's just a question of which way 
> is more elegant (or more Zen, as some people would say ;-).

They're both Zen, but for different models. My original idea for IPC
was that you would eventually be able to write programs in it,
graphically, the way you can with UNIX pipelines. You just have your
programs that act as generators and filters and stick them together
with lines in a patch-panel sort of thing. Like if you wanted to filter
an IFF image you'd have your "ILBM" icon which reads an IFF file and
wraps it in a message and writes it to its output port. Your filter icon
would take the ILBM and do a transform on it. Your display icon would
take the ILBM and pop it up. If you wanted to edit it or save it instead
you'd pop in the appropriate icons.

It seems this would be easier with PPIPC, but it shouldn't be impossible
with OOIPC. Why don't you two guys take a crack at it?
-- 
-- `-_-' Peter (have you hugged your wolf today?) da Silva.
--   U   Mail to ...!uunet!sugar!peter, flames to alt.dev.null.
-- "Running OS/2 on a '386 is like pulling your camper with an Indy car"