FreeTDS Development Group

[entropy AT freetds.org]

James K. Lowden wrote:
> Frediano Ziglio wrote:
>
> > > We do not yet have a reliable way to do this, because each client
> > > library has its own convention for handling timeouts.  Db-lib and
> > > ct-lib expect different error codes and return different values (and
> > > have different semantics).  Meanwhile, libtds does  not know which
> > > client library established the connection, and thus cannot know what
> > > semantics to use.  The solution to *that* is to create a consistent
> > > interface to libtds, and let it call out to the client library, which
> > > will in turn invoke the handler and return a consistent error code to
> > > libtds.  Obviously, a first step would be to modify TDSSOCKET to
> > > record the client library in use.  
> >
> > Whatever library all libTDS has to know is how to behave in timeout
> > situations... this should be possible using current timeout callback.
> > IMO what should be revised and tested should be dblib/ctlib behavior
> > (dblib particularly).
>
>
> Agreed.  Keep in mind that the application's handler will be different,
> depending on whether it's db-lib or ct-lib.  The rules are different, even
> though at the tds layer it all boils down to retry/abort.  That's why each
> library needs its own intermediary to interpret the handler's return code
> and convert it into libtds's single form.  To do that, libtds has to know
> which intermediary to call.  
>
> application
>     API library
>         libtds
>             goodread (or whatever)
>                 error
>                 determine API
>                     API intermediary
>                         application's error handler
>                     convert API return code to libtds code
>                 retry or abort
>
> I hope that's clear.  Tell me if not.  

I agree with Freddy.  The API return codes should never leave the API 
and its applications.  All interfacing to libtds should be done in the 
callback routine that the API registered with libtds.  Then there is no 
need for libtds to know or care which API is involved, and it doesn't 
need to be polluted with API-specific codes.  The "API intermediary" 
should be provided by the API itself, and all libtds then needs to do is 
call it.

--
Cheers,
entropy