joshua@athertn.Atherton.COM (Flame Bait) (06/16/90)
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: >joshua@athertn.Atherton.COM writes: > >>Like programming languages, different RPC protocols have different strengths >>and weaknesses. Different problems will require different RPC systems; one >>size does not fit all. I do not see what the gain is in having OSF (or UI) >>choose one RPC system as "standard". Why not support all the common RPC >>systems? There are only 2 or 3, they each have special strengths and >>weaknesses, and do not interfear [sic] with each other. >It is a good idea for vendors (and users too) to standardize RPC's >because your comparison to programming languages _is_ a good one. I think you missed the point of my posting, which was described in the paragraph before the one you quoted: the difference between user companies (where standardization is good) and vendor companies (where different choises should be supported). If you want user companies to standardize on a language or RPC system, then the vendors can't force the issue. The vendors must support more than one language (and hopefully more than one RPC system) so that the user companies can choose what is best for them. Currently, both OSF and UI support C, FORTRAN and PASCAL as primary languages, as well as having AWK, ADA, and lots more available on their machines. Think of the uproar which would happen if OSF announced that only FORTRAN would be supported. No one seems upset that Apollo (for example) ships and supports C, FORTRAN and PASCAL; no one says they should standardize on one programming language. The same should be true of RPC systems. Joshua Levy (joshua@atherton.com)