Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!columbia!lamont!paulf
From: paulf@lamont.ldgo.columbia.edu (paul friberg)
Newsgroups: comp.databases
Subject: Re: data base client/server communications
Message-ID: <2097@lamont.ldgo.columbia.edu>
Date: 8 Feb 90 15:16:17 GMT
Distribution: na
Organization: Lamont-Doherty Geological Observatory N.Y.
Lines: 34

Thanks to all who have replied to the questions regarding
client/server data base communications. Many of the responses have
been quite helpful.

One issue that still bothers me is the creation of intermediary
communications servers:

Jon Krueger (jkrueger@dtic.dla.mil writes:
>> 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.

Some questions to your reply, aside from the point made by Mike Olsen
(about separating the protocol code from the application for compiling
reasons i.e. his 6 x 50 example), why use a separtion mechanism if 
you are going to give up performance? Why not use a library for the
network code? What does security have to do with a separation mechansim
any way? Can't that be implemented straight up through a library just 
the same?  I personally feel that efficiency should rule on the 
side of performance.

Paul Friberg
 @ Lamont-Doherty Geological Observatory of Columbia Univ.
----------------------------------------------------------------------
Inet:   paulf@lamont.ldgo.columbia.edu
Analog: (914) 359-2900 x620