Skip to Content.
Sympa Menu

freetds - Re: Proposed new FreeTDS configuration format

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT speakeasy.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Proposed new FreeTDS configuration format
  • Date: Wed, 30 May 2001 02:08:57 +0000


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.





Archive powered by MHonArc 2.6.24.

Top of Page