FreeTDS Development Group

[ZIGLIO Frediano <Frediano.Ziglio AT vodafoneomnitel.it>]

> 
> > > TDSLOGIN is the wrong place to put this.  I would strongly
> > > recommend placing it in the TDS_CONTEXT structure (which is
> > > currently only used in dblib which has a implicit context)
> > > and allocating that within cs_ctx_alloc() for ctlib and
> > > SQLAllocEnv() for ODBC. Let's discuss implementation on list.
> > > 
> > Ok, let's talking about. Your guess is true, I finally add 
> stuff in TDSLOGIN
> > very fastly, perhaps isn't the good place. 
> > 
> > TDSSOCKET seem the good place to replace global variable. 
> > I used TDSLOGIN because timeout setting are placed also in 
> TDSLOGIN. You
> > suggest to use TDSCONTEXT but tds sources have no refereer 
> to TDSCONTEXT,
> > only to TDSSOCKET. 
> >
> > Configuration must be available at connect (or before) so 
> perhaps instead of
> > passing a TDSLOCINFO to tds_connect we should pass another param
> > (TDSCONTEXT? ).
> >
> > freddy77
> 
> TDSCONTEXT holds locale information and a connection list 
> (replacing the
> previously global connection list variable).  I truely think this
> container is the place to store API-wide attributes.  My 
> concern is that
> ctlib and ODBC allow for multiple contexts.  It's actually 
> very rare for
> an application to use multiple contexts but it would be the case in an
> apache/perl/php/etc... configuration.  If the API wants to 
> play games in
> changing the message handling function it's still free to do 
> that without
> chasing down every socket and login structure.
> 
> Now, the problem with this scheme.  It was my intention to add the
> TDSCONTEXT field to CS_CONTEXT and remove TDSLOCINFO from 
> there.  Also in
> ODBC we'd need to add it to _henv and remove loc from that as well.
> 
> tds_process_msg() needs to be able to look up the handlers 
> (and probably
> eventually locales) so a pointer to the active context should 
> be stored in
> TDSSOCKET.
> 
> This was the direction the code was going, but if you want to 
> remove the
> globals, feel free to do the heavy lifting. ;-)
> 
> Brian
> 
So... 
TDSCONFIGINFO store information from configuration file
TDSLOGIN store information for login process and some login configuration
(such as query timeout)
TDSSOCKET store information for connection
TDSCONTEXT should contain information for every API type 

TDSSOCKET should have a reference to TDSCONTEXT

Perhaps a method to achive this is add a TDSCONTEXT reference to TDSSOCKET,
store all needed module info in TDSCONTEXT. Also module can extend
TDSCONTEXT in a OO-like mode like:
typedef struct cs_context {
        TDSCONTEXT tds_context;
        ... other context info ...
} CS_CONTEXT;

Also we must pass TDSCONTEXT to tds_connect (removing TDSLOCINFO)

At this point I'd remove connection_list from TDSCONTEXT, add pointer for
msg/err handler 

Have I understood ?

What about adding a void* pointer to mantain additional data for every
socket ?

freddy77

=================================
"STRICTLY PERSONAL AND CONFIDENTIAL

This message may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
The contents of this message that do not relate to the official business of
our company shall be understood as neither given nor endorsed by it."

=================================