On Wed, Feb 19, 2003 at 05:29:25AM -0500, Alan DeKok wrote: > I guess I'm confused when I remember an email from the freetds > library developers, who told this list that the rlm_sql_freetds module > was using an unsupported API for freetds, and wouldn't build or link > to the freetds library.
He's right that the README is pretty useless about communicating this. It says the module 'may not build', but fails to provide a pointer to rlm_sql_sybase, the module which is written to a stable API (one defined by other vendors). I'll commit a comment to CVS to this effect. Given that even the most studious documentation reader is going to waste more time than is warranted looking at rlm_sql_freetds simply on the grounds that the name coincides with the name of the SQL libraries they're using (FreeTDS), I'd just as soon see this module removed altogether or moved to a different CVS module. The libtds that rlm_sql_freetds uses not only has an unstable interface, it provides almost NOTHING in the way of protocol abstraction -- maintaining rlm_sql_freetds is not worth it, IMHO, because code may have to be added for every new variant of the TDS protocol that needs to be supported (and there are four in common use today -- two MS-specific versions, one Sybase-specific specific version, and one "backwards-compatibility" version common to both). libtds provides a useful common library on top of which to implement the standard API providers (CT-Lib, DB-Lib, ODBC) within FreeTDS, but I really don't like to see public code using this lib outside of FreeTDS itself. -- Steve Langasek postmodern programmer
msg13969/pgp00000.pgp
Description: PGP signature
