FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

entropy AT freetds.org wrote:
> James K. Lowden wrote:
> > 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.

I'm not sure there's any disagreement.  

Each API has its own rules about error codes and return codes.  I've
looked at it carefully.  The way the handler indicates how to proceed
differs.  I don't believe it's possible to unify them merely by choosing
the #define constants carefully.  

If libtds were to call the handler directly, there's no opportunity for an
intermediary to translate the handler's return code.  

If we agree that 1) the handler's return codes will differ by API, by
design, and 2) there should be a translation layer to convert them to a
canonical form, and 3) that that translation layer (my intermediary)
should reside in the API layer, then we should also agree that libtds
needs to know which intermediary function to call.  It can itself be
registered (perhaps that's what you meant?) or libtds can know which is
the controlling API and look up the appropriate intermediary.  

I had been thinking that libtds would look up the intermediary by API.  I
see now that the application can register with the client library, and the
client library can register with libtds.  I like that approach better; I
wish someone had suggested it earlier.  

Either way, the call stack is the same:

(app)   handler
(api)   intermediary
(tds)   libtds error branch
(tds)   libtds
(api)   API
(app)   application

Regards, 

--jkl