FreeTDS Development Group

["James K. Lowden" <jklowden AT speakeasy.org>]

Brian Bruns wrote:

> # The freetds.conf file is a replacement for the original interfaces file
> # developed by Sybase.  You may use either this or the intefaces file, but 
> not


^^^^^^^ :-)

> # Only hostname, port number, and protocol version can be specified using 
> the
> # interfaces format.

(making it easier to understand, document, and use)

> # The conf file format follows a modified Windows INI style (or Samba style 
> if
> # you prefer to think of it that way).  There is a [global] section which 
> will
> # affect all dataservers or basic program behaviour, and a section headed 
> with
> # the dataserver's name which will have settings which override the global
> # ones.

I vote for [global] cf. Samba if it's still up for debate.  Since James's main
concern was having a database by that name, and the more like Samba it is, the
better.  For instance, Samba uses the name "workgroup" where you've opted for 
"nt
domain".  I think the latter is clearer, but might Samba alignment pay off 
later?

> [global]
>         tds version = 5.0
>         initial block size = 512
>         swap broken dates = no
>         swap broken money = no

I like this very much.  What is the relationship of the values in [global] to 
the
environment variables?  Can we do away the environment variables altogether?

+++

Hi Brian,

I think this is marvelous, by the way, an important feature.  What's the 
right thing
to say here?  Attaboy?  Thank you for tackling this.

A few thoughts, some whacky, no doubt, for your esteemed consideration:

1.    FreeTDS should mimic the behavior of the native client insofar as 
possible, and
require as little of the user as possible.  For instance, why should the 
library need
a {try | don't try} option for domain/server authentication?  Why not: Just 
Try?  The
MS client uses trusted logins for any connection for which the client doesn't
explicitly set a username.  And it definitely *should* be per-connection.  The
trusted login is a kind of default environment; overriding it with a username 
is
useful to alter the privileges of a particular application or interactive 
session.

2.    Can I say I don't like specifying the TDS protocol version?  I think 
the user
should specify Sybase/MS and the server version, and FreeTDS should pick the 
best TDS
version.  Is there any reason anymore not to run the highest supported TDS 
version
for a given server environment?

3.    I suggest we dump interfaces completely.  Sybase did, Microsoft did.  
It's a
dodo.  I'll send you some perl (or C++, if need be) to convert an interfaces 
file to
a skeleton freetds.conf if you think it could be incorporated into the FreeTDS
installation.

4.    If we dump interfaces, we can do away with $SYBASE, too.  Why not 
replace it
with $FREETDS, pointing to freetds.conf?  If ~/.freetds.conf is honored before
$FREETDS/freetds.conf, we can dump all the environment variables.

In sum, freetds.conf is flexible enough to incorporate all the environment 
variables
(including $SYBASE) and the interfaces file.  It should contain what the user 
knows
or can ascertain about his environment.  Authentication should be 
per-connection,
relying on trusted logins in the absence of a username.

I hope this is useful, sir.  If I'm making work, say so.

--jkl

PS.  Do you really think another plain-vanilla .conf file is going to get 
anyone
excited?  Why not invent a whole new hierarchical storage format, not a file 
system,
and call it, oh, "The Registry", and hide the data in it and charge everyone 
for
developing two brain-dead APIs to it?   Then, you could make it mind-numbingly
complicated and hard to use, embed all sorts of non-portable hardware stuff 
in it,
and make the thing so fragile everyone will treat it with kid gloves, while 
you get
credit for a brilliant visionary centralized configuration strategy!  No?  
Well, just
a thought.  World domination is good for the winners, you know.