Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!vrdxhq!dev!dgis!jkrueger From: jkrueger@dgis.dtic.dla.mil (Jon) Newsgroups: comp.databases Subject: Re: data base client/server communications Message-ID: <747@dgis.dtic.dla.mil> Date: 6 Feb 90 15:39:38 GMT References: <2042@lamont.ldgo.columbia.edu> <3234@infmx.UUCP> <1990Jan27.200543.3120@odi.com> Distribution: na Organization: Defense Technical Information Center (DTIC), Alexandria VA Lines: 60 dlw@odi.com (Dan Weinreb) writes: >Your reply and Mike Olsen's both explain why it's a good idea to keep >the network communication code distinct from the rest of the code, and >that all makes a lot of sense. But I don't see why they need to run >in different Unix processes. Need to? If one has separation mechanisms one is wise to use them. We don't need to run software at all, or have online databases. If we choose to, and also aim at reliable systems and correct data, why refuse to use available mechanisms? Plus, anyone who is serious about security needs to prevent direct access to data of any sort. >It seems that the network communications >code should be a library, and there would be various different various >for the different environments; you'd just link together the pieces >that you need into a single executable and run it in one process. This option is always available. The option to separate raw access to data into a separate trusted process is only available if the operating system supports it. Fortunately, most do. >Perhaps your answer to this is "because we want to avoid the need to >re-QA, etc". But it seems to me that when you run the basic database >engine with a different network protocol, this should be QA'ed whether >or not the new network code is linked into the same executable, or in >a separate executable and a separate process. That is, whether or not >you use a distinct process would seem to have no bearing on the need >for QA. QA is not a magic wand that somehow spots bugs or ferrets out badly designed or implemented software. QA is not a philosopher's stone that transforms less reliable code into more reliable. You're using "QA" as if it allowed one to attain equally reliable software regardless of tools used. On the contrary, QA consists in large part of finding out what the relevant tools are and insisting that people use them. The QA analyst would be very interested in why one would throw out the protection afforded by separate processes. QA is not application of tests: that's QC. Your QC folk will happily apply the same tests to the function call model as to the two-process model. If they get the same results, they will either pass or fail both. When they behave differently in the field the QC staff will (quite validly) point out that it's not their fault: they did their job. It's QA's job to point out that one thing we've learned about software is that absence of bugs isn't presence of quality. (The bad news is you still have to test: it's necessary but not sufficient). Also, QA is not a verb: one does not "QA network protocols" nor does one "re-QA" anything. You're hardly alone in this usage, but it's wrong. You're turning an acronym into a transitive verb, forgetting that it already has a verb: assure and its object: quality. One can assure quality: one can not "QA" anything. My personal belief is that this usage tends to mislead the hearer into thinking QA is magic. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger The Philip Morris Companies, Inc: without question the strongest and best argument for an anti-flag-waving amendment.