FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Thu, 10 Apr 2003, Lowden, James K wrote:
 
> Several of us have noted that the ct-lib API closely mimics the TDS
> protocol.  It was Sybase's second try, and it shows.  (It also suffers IMHO
> somewhat from Fred Brooks's "second system syndrome").  One radical
> hypothesis: ct-lib should be libtds.  IOW, db-lib and ODBC could be
> implemented in terms of ct-lib.  After all, what can they do that ct-lib
> can't, if ct-lib can do whatever TDS does?  

Ack! Some things to think about: MS TDS will diverge more and more with 
time, so the ctlib is tds argument may not be true inperpetuity.  Also 
this does nothing to solve the libtds does too much argument, qute the 
opposite.  It also suffers from the ODBC-as-second class citizen problem.

Second argument against, Sybase does not do that either.  Although libs 
below libct (libcomn libintl etc...) are shared.

> Another way to look at it is that libtds encompasses more than it needs to.
> I think it's important that wire-level differences in the TDS flavors be
> isolated from the client libraries.  There shouldn't be any tests for TDS
> version or endianism outside libtds.  There are some utility functions, like
> conversions, that it can do.  But it's not terribly clear to me that we want
> three client libraries all interpreting tokens coming off the wire.  It
> seems to me that one could do that job better.  

non-tds common stuff should be split off, definately.  libtdscomn?  One of 
those never gotten to projects, since once upon a time that was 
only conversion stuff.  Now it's convert, iconv, numerics, portable string 
functions, threadsafety, et al.
 
> Does any of this make sense to you?  Is it tempting, or tempting fate?  
> 
> If you like the idea, we could talk about how to create a merged ct-tds-lib.
> For the time being, db-lib and ODBC would continue to use libtds as it is.
> In the future, they'd attach themselves to the new ct-lib, and the old
> libtds would be retired.  
> 
> If you don't like the idea, perhaps you could describe the changes needed in
> the result processing functions, we can better understand the implications
> of the choices?  

my vote (for what it is currently worth) is to change libtds as needed, 
radically if necessary.

Brian