FreeTDS Development Group

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

<Frediano.Ziglio AT vodafone.com> wrote:
> Today I started fixing problem using compute results.
> 
> Mainly in token.c there are 5 function to process tokens
>  tds_process_cancel
>  tds_process_result_tokens
>  tds_process_row_tokens
>  tds_process_row_tokens_ct
>  tds_process_trailing_tokens

Plus tds_process_default_tokens().

> As usually I never liked the use of tds_peek/tds_get_byte and similar in
> higher libraries. 

I have never liked the organization of token.c, and I especially find it
hard to know who's reading the token.  

TDS has a very predictable structure: token, length, data.  The functional
flow should always be:

        read token
        read length (except login packet)
        allocate memory
        read data
        call token handler, passing data
        free data
        send response, if any

Today, the token handler allocates memory and reads its own data.  By
localizing that logic, libtds would become much easier to understand. 
Most of libtds's job is *parsing* packets, but that's hard to see with its
read-a-byte, read-a-string, read-another-byte approach.  I think
localizing the wire handling would lead to better cancel, done, and
timeout processing, too.  

The cost, of course, would be a buffer copy.  One "raw" packet buffer,
unparsed, read by the wire reader, and one parsed packet (a row buffer,
say).  

Today, the token handler sometimes reads the next token and sometimes
determines the next function to call (which is sometimes itself).  That
spaghetti calling chain constitutes implicit state information. It would
be better to keep the state information explicitly in the TDSSOCKET.  

My idea is really two:

1.  Have one token reader.
2.  Have one packet reader.

If you think the cost of #2 is too high (especially for some tokens), we
could still have #1 (which would improve the logic flow), and keep some
(few) specialized packet readers for efficiency.  

What do you think?  

--jkl