FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno sab, 26/11/2005 alle 17.13 -0500, James K. Lowden ha scritto:
> 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.  
> 

Now I understood your confusion. You are confusing application handler
with library handler... libtds call handler that library give so library
usually pass it's own handler, not application one directly.

> 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.  
> 

This has been discussed and represent the current implementation. For
instance for dblib libtds calls dblib_query_timeout which calls client
dbchkintr/dbhndlintr.

> Either way, the call stack is the same:
> 
> (app) handler
> (api) intermediary
> (tds) libtds error branch
> (tds) libtds
> (api) API
> (app) application
> 

bye
  freddy77