Path: utzoo!mnetor!uunet!van-bc!root
From: ubc-vision!mtsg.ubc.ca!Paul-Andre_Panon@van-bc.UUCP
Newsgroups: comp.sys.amiga
Subject: re: IPC - a proposal
Message-ID: <1693@van-bc.UUCP>
Date: 15 Mar 88 06:08:30 GMT
Sender: root@van-bc.UUCP
Lines: 60


 
 This is my first posting to the net so I hope it goes through all right.
 
 I think that some kind of clearing house for setting up IPC is important and
that some alternative to the Forbid(); - Findport(...); - Permit(); sequence
currently in use is important.
 
 First an example: suppose I have my super integrated-package, it does spread-
sheets, database, word processing and communications functions. All these
are really separate modules which pass messages to eachother telling eachother
what's been changed so that the spreadsheet re-calculates because it gets
told by the database that something has been changed ( a la Excel w/ DDE but
on a wider scale). Now that can be hard wired with a limited number of ports
being recognized so that each module only knows about the other modules that
came with the package. What happens if I've forgotten something in my
implementation because of time/money/market/delivery concerns? Maybe my
package only does two-D graphs for instance. It's very hard for somebody
else to come along and provide a good 3-D plotting module as an expansion
(Actually this is a guess, but *I* wouldn't relish doing 1-2-3 add-ons).
Anybody who wanted to do add-on modules would have to take apart your code to
figure out how to patch in and make itself known to the other modules.
 
 On the other hand, if we do have a standard clearing house for different
processes to find out what other processes might be interested in a subject
(Kind of a process dating service :-) ) with some standard categories and
formats such as we have for IFF, it could make things much simpler.
  
 The ideal would be if you could create your own integrated system (but from
a business point of view, not a programming/hypertext POV) whereby you find
the spreadsheet that suits you, your favourite word processor and drawing
programs happily intercommunicating. They wouldn't even have to be from the
same company but you could have Wordperfect, an SQL package, and Excel clones
intercommunicating/updating eachother's data and improving your efficiency.
Having a standard for doing such things would make such programs more quickly
available because you wouldn't have everybody re-inventing the wheel every
time.
 
 So why take a look at it from the business stand-point instead of through the
integrated compiler approach? Because for business integrated software there'll
always be something that somebody wants that isn't in your package. If Pete's
programming service has an add-on that fits the ommission in your program  
then you'll sell more copies and that's to your advantage. After all, the
add-on features for 1-2-3 almost certainly have something to do with its
success. Can you say AutoCAD? I knew you could. If you don't care about
improving your tools too much and are satisfied with your current environment,
you should still care about how successful your end product will be (Assuming
you plan on selling software).
   Any comments? (I hope I didn't get too preachy but I tend to climb
on soapboxes too easily).
 
P-A
~~~
 
-- 
-- Don't use the reply addresses in my message headers. Instead please use...-+
--                                                                            |
-- INTERNET: userpap1%UBC@um.cc.umich.edu                                     |
-- UUCP:     {ihnp4,alberta,watmath,uw-beaver,uunet}!ubc-vision!ubc-mts!userpap1
-- BITNET:   userpap1@UBCMTSG ------------------------------------------------+