On Thu, Nov 04, 1999 at 07:45:29AM +0100, Tom Ivar Helbekkmo wrote:
> One thing I've failed to understand from browsing the Coda
> documentation: _why_ is there a private re-implementation of RPC?  A
> brief summary of the reasons for this decision would be interesting,
> if someone has the time to respond.  (They must have been rather
> powerful, to be worth absorbing the cost of implementation and
> debugging, I assume?  This is difficult territory, and I was not
> surprised back when I tried to get Coda running under NetBSD before
> you folks did, and I gave up when, after many hours of debugging and
> modifying rpc2, I still failed to get authentication working.)
> 
> -tih
> -- 
> Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"

I surely don't know all the reasons, but maybe some of them.

- RPC2 was used by AFS2. 
 Some of the system on which Coda is built was jumpstarted by using
 the AFS2 codebase to quickly get to a working implementation.

- Available technology the the time it was developed.
 TCP was in it's infancy, memory-usage and filedescriptor usage were
 the limiting factors for any network service. (think of select that
 could only handle 32 filedescriptors)

- Design objectives.
 You could as well ask, why DCOM, Corba, RX, etc. Or for that matter
 C++, Java. Or NFS/AFS/Coda, or Windows/Linux :)
 Also the multirpc implementation does a very good job at sending a
 single message to a large group of peers, without using multicast. This
 is vital for the callback breaks. Also the streaming 'side-effects' for
 bulk datatransfer, which work very well when sending one data stream to
 a group of servers, as used by Coda's active replication. There is
 simply no serious alternative without losing functionality. Which is
 also the reason I was mentioning the possibility of layering
 rpc2-on-tcp. That is not to preserve compatibility, but to preserve
 functionality of the existing implementation.

- Research.
 Multiple implementations of the same concept improve overall
 understanding of the underlying theorems.

- Availability of alternatives.
 Maybe there weren't good alternatives available 12-15 years ago.

- Portability and support.
 Ok, this is a bad excuse, but I heard it a couple of times and the
 reasoning goes a bit like this.
 What if we use product xxx to handle yyy. Well, we could, but what
 if they don't port xxx to platform zzz. Or what if they stop fixing
 bugs we find. And at some point, for some reason, implementing,
 bugfixing, and porting the code yourself looks simpler than leveraging
 off other people's sweat and tears. Luckily, the idea's behind OSS
 seem to be changing that rapidly.

f.i. switching Coda-lwp to pthreads is possible, I even have a fully
 working `glue'-layer, but we lose _all_ windows ports until a pthread
 compatible api is available on those platforms. Also GNU Pth seems to
 work exactly like LWP, and could actually be used as a drop-in
 replacement. But as it is, LWP is fast, relatively bug free ;), and
 the only drawback at this time, as far as I'm concerned, is that gdb
 isn't able to switch the stacks of the LWP-threads.

 Also recently persistent memory stores have started popping up (hmmm,
 how old is RVM by now?), Coldstore, texas, etc. They seem to require
 compiler/linker hacks and are more focussed on C++ programs.

Jan

btw. You hacked on Coda back in the Mach day's? Wow, impressive.