Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request From: cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) Newsgroups: comp.sys.sun Subject: Re: RPC Technologies Keywords: No Digest Subjects in Unmoderated Mode Message-ID: <2991@brchh104.bnr.ca> Date: 4 Jun 91 18:40:00 GMT Sender: news@brchh104.bnr.ca Organization: Sunspots, Psuedo-Unmoderated Lines: 81 Approved: sun-spots@rice.edu X-Original-Date: Mon, 13 Aug 1990 17:06:16 GMT In article <4c2d2946.20b6d@apollo.HP.COM> (Nathaniel Mishkin) writes: >I guess I don't see why it's an odd defense. I'm not pointing my finger >at any one else. I thought I was making a humorous analogy. I guess >I mixed up my complaints about Netwise's lack of (what we call) "transport >transparency" (i.e., ensuring constant call semantics regardless of what >transport you happen to be running RPC over) with my complaints about >customization. The analogy was that building a system that sometimes >yields one call semantics and sometimes another (depending on what >transport the application was running over) was like having a C compiler >sometimes preserve registers (that contains useful values) across calls >and sometimes not (depending on what hardware architecture the C compiler >was targetted for), yielding different program behavior. Fortunately for most programmers they specify "connection-oriented" and get the exact same behaviour as NCS's connection oriented dressing over most other transports. You are absolutely correct that if the programmer say's "I'll take _any_ transport." The one they get will always work but may not maintain strict procedure call semantics. And yet, if they as for connection oriented transports, they will always get reliable at most once semantics, unlimited argument size, and all those other nice things that one may want at the expense of keeping some state of the connection around. I've heard the argument that it is "more efficient" for NCS to maintain that state than it is for the kernel to maintain that state but state is state. Even the ECMA people recognize this is a better way to implement these semantics and specify TP4 as the underlying transport for ECMA 127. >I'll try to re-draw the analogy to apply to customization. If someone >said to a C compiler writer: "Hey look, I know what I'm doing and I >don't want you to save registers when I make this call; give me a way >of telling the compiler to not save registers", I think people would >argue that that kind of customization is a bad idea. And your entire argument goes up in smoke. You see, someone _did_ say that to C compiler writers, and they _did_ say *I must have this* because some people _do_ know better and they _don't_ want to have your choices forced down their programmatic throat. In the C compiler arena these are called "#pragma" statements and at least one C compiler I know of lets you completely redefine the way in which calls are made by the compiler! And guess what that's in the standard too! Your belief that your customers don't want to be able to customize their network applications is unfounded. There are people in both camps. There always will be, NetWISE and Sun have always tried to cater to both because they are all customers. >All I know is that it has always been my impression (reinforced, BTW, >by things that marketing people tell me) that there's a large body of >programmers to whom "network programming" is a daunting prospect. This is a tautology. You could just as easily say that there are a large body of _people_ to whom "programming" is a daunting prospect. But that doesn't justify making BASIC the only programming language. >I have always taken the RPC model as a way to help those programmers by >hiding the network from them -- to relieve them from having to understand >things that you and I understand only too well. I am trying to develop >a system where, as the system evolves, programmers have to know less >and less about the network. In service of this goal, I try to make it >the case that the system doesn't require me to talk about "CL vs. CO" >in describing the system to its users. I like it, a shade on the "I know better than you" side but it shows a strong conviction. Would you feel better if we put using "connectionless" transports in the advanced section of the manual? I think everyone can agree on the goal, but most programmers disagree with the philosophy that "we will decide what is best for you." That reeks of proprietaryness. Think of it like a car manual. The first few pages start off with how to start the car, shift gears and turn on the headlights. By the time you get to the end of the NetWISE manual you can swap out carburetors and reset the timing for maximum performance. Halfway through your manual it says "no serviceable parts inside, go see your dealer." Sorry but that doesn't cut it. -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: 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!"