FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO Frediano [mailto:Frediano.Ziglio AT vodafone.com]
> Sent: December 5, 2003 5:04 AM
> 
> Well, time for rc release ??

I've been working toward it.  As you say, the documentation is the biggest
remaining todo.  

I'm revamping doc/Makefile.am.  I created userguide.dsl.in; it will let us
customize the DocBook stylesheet.  Two benefits: 1) little graphics for
tip/warning/note, and 2) the .html filenames will be based on the name of
the section (<section id="pagename">).  I also updated the Unicode appendix.


BTW, in researching Unicode, I found out that "utf-8 ucs-2 ascii" in Google
returns our very own User Guide as item #1!  Unfortunately, it links to a
page named "a2698.htm".  Since we are apparently a resource on this topic, I
thought it would be a good idea to be able to control the names, so the link
doesn't break the next time we update the UG.  

I'm not done, but you can see the work in progress,
http://www.schemamania.org/projects/freetds/build/doc/userguide/index.htm

> I execute the test on
> - RH7.1 MSSQL2K with unixODBC
> - RH9 Sybase 11.9.2 with unixODBC
> So all tests passed successfully using either TDS5 and TDS8. 

Excellent!  

> - EILSEQ definition. IMHO we already define EILSEQ to GNU version. If
> anyone encounter a problem with EILSEQ should use 
> --disable-libiconv or
> GNU iconv. If iconv do not use EILSEQ surely this is a ugly iconv
> version and should be avoided...

OK, let's postpone it.  

> - locale_charset and nl_langinfo. FreeTDS never used 
> locale_charset nor
> nl_langinfo so IMHO this issue can wait...

OK.  We should try to get the client's encoding from nl_langinfo(), and use
freetds.conf as an override.  

> - ct_dynamic. Code is in CVS... do we need some tests ?

That would be a good idea.  Can you adapt something from the ODBC tests?  

> - UTF-8 test. We already have some tests for UTF-8. IMHO can wait.

Actually, I'm satisfied with the tests we have, for now.  

> - userguide and FAQ. This is the bigger TODO... I readed one more time
> UG and some parts are not that clear/correct
>  - OS-specific Issues (chapter 2)
>   - VC++ projects are present only for ODBC driver
>   - projects for Dev-C++ are also present (only ODBC)
>   - makefile for MingW are prosent (ODBC)

Ah, OK.  Basically, Win32 development is set up only for ODBC.  

[ODBC issues]

I'm going to re-write and reorganize the ODBC documentation, since I've been
complaining about it for, oh, a year or more, and no one's stepped forward.
We discussed a better organization; I'll look over those notes.  One goal is
to make clear the relationship of odbc.ini and freetds.conf.  Another is to
separate DM issues.  We need separate sections for setups that use odbc.ini
+ freetds.conf, odbc.ini only, and freetds.conf only.  And I think the
nomenclature should reflect the "only-ness" rather than the "-less" names we
use now.  If we say, "You can set up your ODBC connection using only
odbc.ini", we shouldn't call that a "conf-less" setup.  

>  - Troubleshooting / Microsoft's "Integrated Security" (chapter 6)
>   - as FreeTDS support now domain logins this server configuration is
> not necessary. This is written in the note but IMHO this part 
> should be rewritten

I'm inclined to agree.  I'd like to leave it in for now.  

>  - Helping (chapter 8)
>   - "The ODBC driver in particular needs work. It's a big 
> API." not that true :)...

Well, how about that?  You're right:

[30] varley.FreeTDS.1> select vendor, status, count(*) as nFunctions from
api where name = 'odbc' group by vendor, status compute sum(count(*))

[30] varley.FreeTDS.2> go
 vendor          status     nFunctions
 --------------- ---------- -----------
 Microsoft       NULL                 9
 Microsoft       OK                  61
 Microsoft       partial              4

                            ===========
                                     74

According to api_status.txt, you're about 80% done!  Who knew?  That means
there's only about 80% left to do!  

It's not clear to me anymore which API is the "weak sister".  If Bill and I
can get the bulk-copy stuff moved into libbpc (instead of db-lib), we'll be
in a position to support bulk-copy from any API.  

>   - "Support for TDS 8.0 is not yet fully working". What don't work?
> Variant... and ?

Noted. 

>   - "Document an API" where does it came the 25% ??

I wrote the db-lib docs.  Brian did some of libtds.  There's nothing for
ODBC or ct-lib.  Let's pretend the first two are half done, and each library
represents 1/4 of the work.  That's where the 25% came from: (0.5 * (1 + 1)
+ 0 + 0) / 4.  

>  - TDS API (chapter 9)
>   - perhaps we should integrate doxygen output in some way ?

Working on it. 

>  - Unicode: East meets West (appendix B)
>   - " Microsoft also designed version 7.0 (and up) of the TDS protocol
> around UCS-2: all character data are encoded according to UCS-2 on the
> wire". varchar/char/text are not coded in UCS-2...

Noted.  

>  - appendix C. Is there a way to put all GNU license in a 
> single page ??

Probably.  I don't see why we should do that.  If we decide to offer the UG
with a variety of html chunkings, we'd want Appendix C to follow the same
arrangement as the main text.  

+++

I'm pretty happy with the functionality we have now.  I'm pretty sure we can
support a UTF-8 client, which to me is a major milestone, even though
there's plenty of internal charset work to do.  Now that ODBC is really
ready for prime time, it needs better documentation, and I'm determined to
do that before the release.  The PHP documentation is also lagging, mostly
because I don't use PHP.  There's no mention of the mssql extension.
Perhaps some of the recent discussion can be adapted.  Volunteers welcome!  

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.