🚀 go-pugleaf

This discussion is great fun guys, keep it up. I'd like you to consider
a paradigm for a moment and see if both of you are talking about the same
thing. It goes something like this :

There are two distinct ways in which Remote Procedure Call technologies
are used. The first (and currently most common) is in the development 
of network services. The second is in the development of distributed
applications. Distinguishing between what type of program you are
writing can make a whole bunch of issues clear. First, lets look at
network services. 

A network service is an application that usually runs on a single
machine.  The application exports to the world "functions" (procedures
for you PASCAL types) which can be called by client applications when
they want to use the service. From the user's perspective there is a
well documented protocol and a bunch of "stubs" that they can call to
access the various exported procedures of the service. These services
are generally things like name servers or remote file servers. In this
environment developing applications is fairly straight forward. The
programmer looks at the "man" page for the functions they need to call
(let's say our name service exports the function "Lookup") and writes
in the code to call that function. The application programmer doesn't
care about "semantics" or "data encoding styles" or whatever. They 
just want to call the function and get a result. Once the application
is written the code is linked with the "stubs" and the programmers
work is done. From the network service developer's perspective, he
(forgive the sexist language) wants to be able to create a service
make it available but doesn't want to become some wizard sockets 
programmer. Here an environment such as ONC/RPC or NCS helps out because
they present a paradigm that looks like procedure calls as opposed to
networking calls and the grunt work is handled by a bunch of library
routines. (Compared to something like 'sendmail' which is very 
difficult to maintain and the protocol somewhat difficult to document)
Here the service designer can decide "how close to the metal" he
wants to write his code because only he knows the true requirements
being made of the underlying network. So to summarize network services,
they are easy to use by application programmers because they just link
to the service's library of client stubs. The service developers 
want to develop services that are reliable and easy to maintain and
the tools provided help them do that.

A distributed application on the other hand is a whole different
beast. Here we have a process (single execution context) which 
has pieces of itself operating on different machines (discontiguous
address spaces). Here the requirements of the underlying distribution
technology become very strict since ideally the system works identically
whether or not any piece of it is distributed. This is where such
overly marketed things like "at most once" semantics (or more commonly
"exactly once") semantics are required. The key differences between
these sorts of applications and network services are that while several
clients may access the functions of a network service, exactly one
client accesses a piece of itself across the network.[ As an aside,
I haven't found any research yet that suggests distributing an 
application has any positive effect on that application, much like
the parallel processor challenge. ] It is still unclear what the
ideal environment for developing distributing applications is, much like it
is unclear about how to write parallel applications in a general
way. (I know, lots of great work but no clear conclusions yet)

Bottom line, you decide. I'm always a bit suspicious when the snowmobile
salesman says "But this is clearly the superior snowmobile! Not very
many people own one so it's distinctive and it is the only one with
air conditioning!"

--
--Chuck McManis						    Sun Microsystems
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"I tell you this parrot is bleeding deceased!"