FreeTDS Development Group

[James Cameron <cameron AT stl.dec.com>]

"James K. Lowden" wrote:
> 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, [...]

Um, no, my main concern was that global is so small.  Something that is
global should be global.  /usr/local/bin is not global.  But if you
think most FreeTDS users will also be Samba users, I can see the point.

> 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?

Because it is difficult for the software to determine the cause of a
failure to authenticate.  I'm assuming the authentication might be out
of band, as it commonly is ... imagine: the TCP connection works, but
the out of band negotiation fails.  Is the server dead, is the router
dead, is my network interface dead, or is it just a packet filtering
firewall whose alarms have just gone off?  I think I'd like a don't try.

> Is there any reason anymore not to run the highest supported TDS
> version for a given server environment?

I thought FreeTDS has no way to know whether it will work.

> 3. I suggest we dump interfaces completely.

I agree, but it depends on how much backward compatibility you want. 
One advantage of open source projects if that you don't need to code for
backward compatibility as much.  One disadvantage of open source
projects is that people don't code for backward compatibility.  ;-}

Having it optional is sufficient.  Failing to document it is the way to
mark it as deprecated.

> 4. If we dump interfaces, we can do away with $SYBASE, too.

I've never used $SYBASE.  Works fine without it.

> PS.  Do you really think another plain-vanilla .conf file is going
> to get anyone excited?

*chuckle*.

Let's store the configuration in a PostgresQL database then.  ;-)

-- 
James Cameron