Proposed new FreeTDS configuration format
James K. Lowden
jklowden at speakeasy.org
Tue May 29 22:08:57 EDT 2001
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.
More information about the FreeTDS
mailing list