Re: tds_connect does too much

"James K. Lowden" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
ZIGLIO, Frediano, VF-IT wrote:
> > 	if (tdsver == 0) {
> > 		for( i=0; i < maxver; i++ ) {
> > 			tdsver = versions[i];
> > 			int fOK = tds_login(tdsver);
> > 			if( fOK )
> > 				return fOK;
> >
> > 			if ((conn = tds_connect()) == NULL)
> > 				return tdserror();
> > 		}
> > 	}

> I don't like this that much... connect on second but not for first...

Yeah, I know.  We need logic like this:

	log_me_in
	  do {
	    connect
	    switch(next(tdsver)):
	    case TDS8
	      tds8_login 
	    case TDS7
	      tds7_login 
	    case TDS5
	      tds5_login 
	    case TDS42
	      tds5_login 
	  } while (!logged_in)

I objected to the name "tds_connect" for something that connects and logs
in.   But maybe it would be OK to have "tds_log_in" (two words: one "logs
in" to a server) both connect and log in.  

I'll work on it some and we can discuss further when we have something
concrete. 


> I never liked that name resolution is in config.c, I thing that should
> be in net.c. 

Agreed.  I'm also not crazy about defaulting to "SYBASE" as a last-ditch
name.  I don't think that does anything except confuse people.  

> To detect problems 
> related to tcp/ip connect in tsql we could test for 
> TDSSOCKET->s, is valid only if there is a connection 

Noted.  

> About naming convention we have
> 
> tds_submit/put_XXX  send packets (query.c) there is also a mix of
> submit/put/send... any  difference ??

Not much.  I like "put" for small things (e.g. fputc), "send" for blocks
of data (e.g. send(2)), and "submit" for whole packets that demand a
reply.

> tds_process_XXX     read and process packets (token.c)

At least it's regular. 

> There is also a tds8_do_login

I think I'd like to rename all those version-specific logins to just
"tds_log_inX" and forget about "send" or "do" or whatever.  

But the weather's supposed to by nice this weekend, so don't hold your
breath.   ;-)

Regards, 

--jkl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.