FreeTDS Development Group

[Dossy Shiobara <dossy AT panoptic.com>]

Hi, James,

On 2008.04.19, James K. Lowden <jklowden AT freetds.org> wrote:
> Both FreeTDS and the AOLserver project would be better off if AOLserver
> used a client library instead.  Concerns about efficiency are misplaced:
> db-lib (e.g.) does hardly anything more than what your own application
> must do to use libtds.  It makes no extra buffer copies, wastes very
> little motion.

Has someone verified thread-safety, all the way through the client
library layer?

This was, IIRC, the primary reason why I went straight to the tds_*
functions rather than trying to use db-lib or ct-lib.  That, and the
primitives that the tds_* functions offers are very useful: reading
through the db-lib API documentation, I don't see how to set the TDS
protocol version any more.  Previously, it was easy as invoking
tds_set_version().  Is this done through dbsetlversion()?  Guess I
should look at the source ...

Does db-lib or ct-lib offer millisecond-granularity timeouts?  Or, is it
in whole seconds?  (Yes, in a real web-based application, fetching data
from remote sources often requires sub-second timeouts.  Or, crappy user
response times ...)

> My criticism isn't intended as unfriendly.  Having written to the TDS
> layer years ago, you'd naturally rather maintain that than re-write
> everything to one of the client libraries.  I just wouldn't want anyone to
> get the impression it was a good idea then or now.  

I appreciate the quick and thorough response!  Thanks.

I guess nsfreetds operates like just another "client library" for
AOLserver application code.  Perhaps I'll look and see what it will take
to build libtds again in 0.82.  Thanks for the idea.

-- 
Dossy Shiobara              | dossy AT panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)