FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

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