FreeTDS Development Group

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

On Fri, 28 Nov 2003, "Don Gray" <don.gray AT vigilantminds.com> wrote:
>
> I have begun reviewing the pool source and would like any input that
> could be provided reagrding the types of changes that should be made to
> support other protocol versions.
> 
> Are the changes "addtional" in nature, meaning that more code needs to
> be added to handle multiple versions or are they "rip and replace" type
> changes that lead to the code currently being used for 4.2 being
> replaced as well?

Don, 

I think you'd find many people interested in a pool server capable of TDS
7.0.  

The pool server is logically three things:

1.  a FreeTDS client application, driven by 
2.  a pseudo-server acting as a server, mediated with
3.  a pool of available connections.  

Obviously, #1 is our strength.  The weak link #2; our server-side code is
primitive and incomplete.  

There's no particular reason the pool server's client and server have to
speak the same protocol, even for a given connection.  Since TDS 5.0
encompasses nearly all the functionality (albeit in different ways) that
TDS 7.0 does, ISTM the server could consistently be TDS 5.0 and map that
onto the client-side protocol.  I would be tempted to do that, rather than
build a multi-protocol server.  

The counter-argument:  For the vast majority of packet types, the pool
server need not understand the internals of packet.  It's really just a
router, and as a router it need only parse the packet header to know what
to do.  Because almost all TDS packets indicate their size immediately
after the token, the pool server can ignore the packet contents, read the
packet's entire contents, and write them to the other side.  

The src/tds/token.c file handles the tokens (packet types) that we
recognize.  If the server code handled them all, you'd be almost done.  

> Can you point me to anything that might not be obvious in other portions
> of the "main" tds code base as a guide?

Brian wrote the pool server, and it hasn't seen much activity since, as
you know.  He's been pretty indisposed lately, so whatever support we can
give you will likely be second-hand.  

> I cannot commit that I can effect these changes but I am serious about
> making an effort to assist this great project.

A better pool server would be a great contribution.  Good luck, and let us
know when you get stuck.  

Regards, 

--jkl