Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: mishkin@apollo.com (Nathaniel Mishkin)
Newsgroups: comp.sys.sun
Subject: Re: rpc registration and how to tell of a cnode death ?
Keywords: No Digest Subjects during Flush
Message-ID: <4029@brchh104.bnr.ca>
Date: 27 Jun 91 20:22:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sunspots, Flush Mode
Lines: 66
Approved: sun-spots@rice.edu
X-Original-Date:    Thu, 13 Jun 91 12:06:06 EDT

First, maybe it has something to do with our site's recent upgrading
of its newe software or maybe it has to do with the recent solar flares
(now THAT would be appropriate :-), but I've seen a ton of postings (many
duplicates) relating to RPC on comp.sys.sun that are in fact from the
spring and summer of LAST YEAR.  These posting I think originated on
comp.protocols.misc.  I don't know why I (or anyone else) is seeing them
now.  I don't read this group regularly so maybe I missed some explanation.

In article <3794@brchh104.bnr.ca>, fkittred@spca.bbn.com (Fletcher Kittredge) writes:
>The supposed strength of the DCE is the integration of the parts; it is
>unlikely that anyone would use NCS 2.0 RPC without the other DCE parts.

This isn't quite accurate.  NCS 2.0 RPC (aka DCE RPC) uses the pthreads
API.  The DCE contains a relatively portable implementation (aka DCE
Threads) of the pthreads API.  Having just DCE RPC and DCE Threads (or
an alternate implementation of the pthreads API) you can do useful stuff.
The next most likely piece of the DCE you'd want is the DCE Directory
service, which supports a replicated, read/write, hierarchical (i.e.,
UNIX-like) namespace.  This service is a big aid to RPC application
developers.  Beyond that, having the DCE Security service would be useful
if you want to do *authenticated* RPC.  Several snapshots (including
a "developer's kit") of the DCE have been shipped by OSF over the last
year.  These snapshots (which consist of source code) are available to
OSF members and DCE licensees.

>I seriously consider native threads to be more of a boon to distributed
>applications writers than RPCs.  Hopefully over time, most environments
>will have POSIX threads, so this *major* advantage of the DCE over Netwise
>will go away...

Gosh, this seems like an apples-to-oranges comparison.  Threads are just
a plain useful programming paradigm.  There's no intrinsic relationship
between RPC and threads.

>By the way, HP employees being ignorant of what the automounter and amd
>are is sooo symptomatic of their failings in the areas of distributed
>computing.  The HP lack of tools for a distributed environment gives one
>the sense that they really don't use a distributed heterogenous
>environment in house.  They don't even have an automounter in their next
>release and it took them till 1990 to get rdump!  

I'm afraid I must have missed the original posting so as far as I know,
it could have been stupid as all get out.  But let's not tar an entire
company and its strategy for supporting distribution applications based
on one posting.

>Also, rewriting a working application which uses Sun RPC to use NCS
>RPC is a stupid idea.

Probably true, at least in some cases.

>There really isn't much difference between the two.

Just so this doesn't go un-noted:  YOU may think there are no differences,
but many people (myself included) think there are a number of important
differences.  I really recommend people look at the existing documentation
for the two systems.  Also, with your vaporware hats on, you should look
at documents describing future product versions of these systems.

-- 
                    -- Nat Mishkin
                       Cooperative Object Computing Division / East
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com
-------