FreeTDS Development Group

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

"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com> wrote:
> Well, our TODO file seems a bi too long (and perhaps outdated)
> 
> Follow some comments
> 
> Broken:
> . Undelimited data files should be read w/ tds_iconv_fread().

freebcp -c uses tds_iconv_fread(); freebcp -n does not.  

Our bcp support isn't very flexible wrt encoding.  It assumes (for
character files) that the client's current charset is the same as that of
the data file, but of course the data file could have been created
anywhere and have an arbitrary encoding.  For "native" files, iconv is not
called, meaning the encoding had better match the server's.  

I'm not sure changing the assumption for native bcp from "same as server"
to "same as client" would fix very much.  

I'll update TODO to make this situation clearer.  

> . Passing invalid character set names to server with tsql?
> ** Fixed ?? What does it means ??

I don't know what it means.  

> Postponed to 0.64 version
> . log and call error handler on problems with tds_iconv_init().

Should call tds_client_msg() when tds_iconv_init() fails, I think.  Have
to invent an error code, because this funcitionality doesn't exist in the
vendors' implementations.  

> . iconv
>   - add test for locale_charset() to configure.in.  Use it if available
>     instead of nl_langinfo, because it implies we're using GNU iconv
> 
> ** really needed ?? We never user nor nl_langinfo nor locale_charset.

If the client application correctly initializes libc, setting its locale
information, it would be nice if libtds noticed.  

> . be able to disable iconv for BCP (see Sybase documentation)

See above.  
 
> . UTF-8 unit tests (libTDS)
>   - very large column name (128 on mssql), no-english to UTF-8 client
> ** should work.  TDS_SYSNAME_SIZE is 512 so it should handle any
> charset.

OK, let's call it done if you say so.  

> . userguide
>   - update table of working configurations
> ** well.. this it's just to remember but perhaps should be removed from
> TODO

If someone wanted to do it, it's a recognized undone thing.  

> Started in 0.63
> - rationalize libtds structure and *_alloc functions
>   (ML 5 December 2002, sb:"names")
>   (remove INFO and others)
> 
> ** left TDSRESULTINFO, TDSCOMPUTEINFO, TDSPARAMINFO, perhaps it's better
> to use TDSRESULTS and similar ??

Done enough, I'd say.  Thanks!  

> For future versions (in priority order within library):
>   All:
> . fix timeout problem reported in ML

Timeout handling is seriously broken.  I don't remember the particular
list discussion anymore, either, but the code makes it obvious enough.  

> . Remove old char(30) limitations to various sysnames e.g., tables,
> columns,
>   passwords (checks).  Is this done?
> ** I think this works since 0.61...

Let's call it done, then.  

> . more solid. handle out of memory conditions (started, we must test all
>   allocation and all function that return allocated data and be able to
>   rollback to a safe state)
> ** Just to remember but I think we reach this quality on 0.61... better
> to place it on doc/CodingStyle

OK.  

> . limit copy of data (now wire -> tds -> temp -> client)
>   use a method like zero-copy
>   In token.c getting row should write data even to client
>   (callback, new user types, see ctlib conversion functions)
>   In query.c writing data do the same (use additional column fields?)
> . review the way parameters are packed
>   (too complicate, see ctlib bulk, cf "bulk copy and row buffer")
> 
> ** James, do you have some declaration for these ??

Not yet, sorry.  

> Done
> 
> ** TODO and done ?? Not that fine

My practice has been to move TODO items to "done" when I'm satisfied
they're done.  Experience may prove contrary, in which case it can be
restored, else it becomes a bragging point for the release.  

After a release, I suppose we should clear out "done".  

--jkl