Re: CS_SERVERADDR tag is not handled correctly in ct_con_props

On Mon, 13 Jan 2014 11:57:12 -0500
Stephen Marshall <[email protected]> wrote:

> In my opinion, the priority of these information sources should be,
> from lowest to highest priority:
> 1. Hard coded defaults
> 2. Environment variables
> 3. Global config values from freetds.conf
> 4. Server-specific values from freetds.conf
> 5. Settings specifically made by calls to ct_con_props

The order is 

> 1. Hard coded defaults
> 3. Global config values from freetds.conf
> 4. Server-specific values from freetds.conf
> 2. Environment variables
> 5. Settings specifically made by calls to ct_con_props

because the user may not have access to the configuration file but
always has access to his own environment.  They don't override 
application-driven settings because the application
may have a need for particular settings irrespective of the user's need
or expectation.  

I thought that was accepted practice, but a quick tour through my home
directory yields very few examples of programs that use both a
configuration file and environment variables.  Of those that do, they
cover disjoint attributes.  For example, the HTML checker "tidy" has a
configuration file, and the only environment variable it honors governs
the name of that file.  xdvi honors a bunch of variables that are
truly *environment* variables, such as VISUAL and TMPDIR, and none that
overlap what might be found in .xdvirc.  

There would seem to be a good case for simplification.  

> The code should be reworked to set connection parameters in priority
> order, with each level in the hierarchy overriding settings in the
> previous level.

That's what it does now.  

> As far as I can tell, such a change would require the connection
> logic to be completely refactored.  This is no small task, 

The problem is well defined and confined to the startup code, basically
config.c.  That code wins no beauty contests today.  It's not awful,
but it could certainly be better.  

A good start would be a proper parser to read the configuration
file, and a data structure to hold the configurable elements (or just
use getenv and putenv).  Iterate the parser over the available files,
and voila.  Write a little standalone test utility to exercise
library and print the results -- helpful for users testing their
configurations -- and then integrate it into the existing system.  

I've often thought the parser could be simplied if the configuration
file grammar were simplifed.  Suppose the structure were:

.freeds/
.freetds/global
.freetds/host1
.freetds/host2

with each file representing a server, containing only lines of the form
	
	# comment
	option = value

Such file could be parsed as a regular language (using regular
expressions) and the user would have an easier time knowing a server's
settings because 

	$ cat ~/.freetds/servername

would work with tab-completion and never yield more than a few lines.  

--jkl