Xref: utzoo comp.sys.apollo:6945 comp.sys.dec:4371 comp.sys.hp:6701
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!athertn!joshua
From: joshua@athertn.Atherton.COM (Flame Bait)
Newsgroups: comp.sys.apollo,comp.sys.dec,comp.sys.hp
Subject: Re: Why So Few Commercial Applications That Use RPC?
Message-ID: <32841@joshua.athertn.Atherton.COM>
Date: 30 Oct 90 03:46:07 GMT
References: <35263@cup.portal.com> <90299.135118RBNTJC@ROHVM1.BITNET>
Reply-To: joshua@Atherton.COM (Flame Bait)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 55

RBNTJC@ROHVM1.BITNET (Thomas J Cozzolino) writes:
> I can't understand why there aren't more RPC-based commercial 
> applications out there.

If you knew the answer to this question, you could make lots of money 
selling it.  Programmers and end users are crying out for distributed 
platforms and applications.  At the same time, vendors are supplying 
pretty good RPC systems.  Yet, there are few RPC based distributed
applications.

> Maybe most software companies aren't prepared for the support that would be
> involved in running a "shink-wrapped" application over a combination of many
> vendors' equipment.  

Perhaps, but there are lots of socket based distributed applications, 
which should have the same problems.

> Another big fear is the Sun vs. HP/Apollo RPC issue that so many of us 
> are tired of hearing about.  Let's get some applications already|

Again, perhaps, but that those fears seem to be limited to Sun and HP.
Each afraid they might loose, I'm not sure that applications writers
really care that much.  I didn't.

The other "usual suspects" for the lack of RPC applications are lack of
debugging tools and lack of partitioning tools.  But I'm not sure I
buy into that, either.

My best guess is that it is inertia.  UNIX communications programming has
always been an arcane specialty.  The people who did it all started with
sockets, and are continuing to use what they know best.  As new people
start doing communications programming they will use RPC more and more.
The arcane aspect also makes companies warry of taking existing applications
and distributing them.  Unless the performance is really bad or the
application really needs data somewhere else, they are unlikely to take
the time and efford to use RPC.  (And of course the applications can't
be that slow or that in need of other data or they would not have been
written in the first place.  Catch-22.)  

Another problem is standards.  Not the Sun/HP conflict, but RFCs.  These
"Request For Comment" documents define various standards, de facto standards
and targets.  They specify all (or almost all) protocols as data passed 
over UDP and TCP.  Therefore, it is impossible to write a standard
conforming SNMP, SMTP, or ARP servers (for example) using RPC.  This
encourages people to use sockets for other server programs they need to
write.  It would be nice if we could see some RFC protocols defined as
RPC specifications, but there are lots of practical problems.  

Summary: I dunno why people don't use RPC for more applications work.
         I did, and it worked fine.

BTW: I read and liked your (Cozzolino's) paper describing your distributed 
     application.

Joshua Levy  (joshua@atherton.com)