FreeTDS Development Group

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

Hildo Biersma wrote:
> Frediano Ziglio wrote:
> > That is current implementation... empty username means kerberos. 
> 
> Can I suggest you add an additional way to trigger Kerberos, for example
> 
> the combination of the userid "Kerberos" and password "Ticket"?
> 
> [...] a lot of vendor 
> applications implement edit checks that a userid and password is not 
> empty; for example, a GUI will gray out the 'connect' button until the 
> userid and password contain a non-empty value.  Having a second way to 
> trigger Kerberos in FreeTDS, by virtue of a special userid and password,
> 
> will avoid these issues.

Implicit in your suggestion is the idea that we need to allow for closed
systems.  I don't believe that's the case.  And I would rather fix actual
problems than prospective ones.  

There are a couple of proprietary applications out there that use FreeTDS,
and probably others I don't know about that use the ODBC driver.  Every
single one of them and their users has access to the FreeTDS source code
and can implement the feature you suggest.  Or they can change their
applications.  

That puts the burden where it belongs.  The vendor can remove the bogus
edit, or add the fake username as you suggest.  The vendor can even
contribute a patch.  If neither, the vendor's customer can add the same
patch[1] or change vendors.  

All these outcomes produce a better application and a better library.  I
think that's better than facilitating poor work.  

--jkl

[1] The LGPL requires that code linked to an LGPL library permit the
person receiving the executable to change the LGPL-licensed code and
relink.  While the distributor can accomplish that several ways, the
effect is always to permit the "distributee" to upgrade the library
without the other's permission or assistance.