No subject


Fri May 2 19:13:14 EDT 2003


In the course of our work, we're making changes to libtds, which we consider to be an internal library whose interface we can change at will.  Someone wrote to our mailing list asking for help, and it turned out that he'd come across a bug we'd already fixed in cvs, so we advised him to get a more recent snapshot, which he did.  Then we found out he was using FreeRadius, and then we found out FreeRadius was using libtds.  And then we found out :( we'd changed the interface to libtds, leaving our FreeRadius friend with no solution (besides vi and a lot of time).  ;)

I think one of our committers is going to offer you a patch to deal with our change, but obviously that's not going to be the end of the story.  For one thing, more libtds changes are in the pipeline, and for another, as you know, coping with our changes will not be fun for the FreeRadius developers and users.  

What to do?  I'm open to suggestions, and have a few.  For starters, is anyone on your side subscribed to our list?  That would help keep you abreast of what's changing.  

It's unfortunate, really, that FreeRadius decided on the libtds interface.  FreeTDS supports three published interfaces defined by Sybase and Microsoft: db-lib, ct-lib, and ODBC.  Any of these is stable.  We're adding to them and correcting them, but we're not changing their definitions.  If one of your team is interested in rewriting the freetds module in terms of db-lib, I would be willing to offer support and guidance.  

At the very least, I though I should say "hi" and tell you our side of the story, so you and your fellows can decide how to proceed.  

Best regards, 

--jkl



More information about the FreeTDS mailing list