FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

On Sep 8, 2011, at 10:08 PM, James K. Lowden wrote:

> On Thu, 08 Sep 2011 12:22:14 -0500
> "Craig A. Berry" <craigberry AT mac.com> wrote:
> 
>> 5.0 may not be a sensible default in this day and age.  But I'm not
>> sure there is a different one that makes sense either.  
> 
> I'd like to riff on that a bit.  The right default might be "auto",
> which is currently supported in, er, CVS HEAD.  
<snip>
> Larry Wall mentioned a similar artifact once in writing about Perl 6.
> He remembered IIRC a setting in VMS mumble something like SET EXTENDED
> ON to make it DTRT.  He observed that thereafter *every* script needed
> that boilerplate in its preamble.  One gets the sense Larry is not a fan
> of boilerplate or, for that matter, preambles.  

I'd be curious what the VMS boilerplate was as I can't think of anything like 
that, though the details are not relevant to your point.  In the Perl 5 
world, a great many bits have been shed in arguments over whether people 
should continue having to write "use strict;" at the top of their Perl 
programs or whether some future version of the language will have that built 
in, breaking lots of existing code in the process.  Balancing forward 
progress and compatibility is never easy, as is somewhat humorously discussed 
today at <http://raganwald.posterous.com/javas-comb-over>.  

> That's the world of binary interfaces and closed source.  Free
> software lets you set the "default defaults" with ./configure.  Because
> you control the source, you can set the default at compile time, which
> is why the inoperability of dbset[l]version went unremarked-on for
> years.

I think the unique difficulty for FreeTDS is that it supports multiple 
versions of two closed-source servers that used to agree on everything but 
got a divorce some time ago and have steadily grown apart since.   The number 
of versions steadily grows and the meaning of a version has become rather 
different for the two implementations.  

> If we were to remove --with-tdsver (which we won't) we'd remove
> only the ability to set the compiled-in default.  If you don't use that
> configure option, you get 5.0.  It has to be *something*, even if it's
> an invalid value that forces you to use one of the runtime or
> programatic methods to set it to something valid.  
> 
> Which brings us back to: what should it be?  
> 
> Which makes me ask: what's a configure file for, anyway?  
> 
> freetds.conf associates a hostname, port, and TDS version with a local
> name.  Hostname is converted to an IP address by DNS or similar.  Port
> is discoverable on Microsoft servers using 1434.  And TDS version can
> be found by starting high and working down.  Old servers reject
> logins using newer versions of the protocol; from their perspective the
> new version is a protocol violation.  By trying successively lower
> version, a client can discover the highest one supported by a server.  
> 
> What that means to me is that FreeTDS in its next release should
> normally be run without a configuration file or environment variables.
> The default-default TDS version should be 0, which tells the login
> function to keep trying TDS flavors as long as something accepts the
> tcp/ip connection.  

Wouldn't it have to be the highest currently-supported version rather than 0 
if it's going to be decrementing on retries?

> 
> That said, there is miniscule overhead in retrying logins, and it is
> unnecessary if you know which TDS version the server wants, and for
> some applications a few hundred milliseconds' delay to log in
> matters.  The spirit of the project demands that users be able to nail
> things down, even to the point of setting the compiled-in default
> behavior.  
> 
> End of Riff.  Thanks for listening.  

Interesting riff.  A slightly different way to balance the problem might be 
to have two configure-time parameters, --dynamic-tdsver-start-version and 
--dynamic-tdsver-retry-limit.  The former is the version for the first 
connection attempt and the latter the number of versions to try before giving 
up.  That way people could make their own trade-offs of speed and 
flexibility. 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser