FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il mar, 2003-05-13 alle 20:00, Lowden, James K ha scritto:
> I thought I'd come up for air and try to take stock, see where we're at.  To
> non-developers following the discussion it must seem at least a little
> bizarre at times.  And a Sense of the Senate might be helpful to us all.  
> 
> As the TODO says, there are a bunch of things going on, mostly connected
> with iconv, of course.  If you look at the current source code, you'll find
> it's littered with FIXME comments also related to iconv.  
> 
> My sense of things is that there's no going back.  We're irrevocably
> committed to generalized charset translation.  There are more changes in the
> pipeline, obviously, but I'm pretty sure we're better off now than we were
> before my iconv embarkation.  
> 
> I think current CVS has returned to its "normal" state for us: better than
> the release, bugs quickly addressed.  Can be recommended to anyone seeking
> help.  
> 
> We should soon achieve stability with UTF-8 clients, and when we do, we
> should start to get ready for the 0.62 release.  UTF-8 isn't stable yet, and
> requires (many) incremental changes, but no fundamental ones that I can see.
> We're marking any size assumptions we come across, and fixing them with new
> functions and more generalized logic.  Pretty soon, the number of such
> comments will start to decrease, linearly approaching zero as we fix more
> than we find.  
> 
> The release will certainly need more than simple stability.  We need a
> locale/charset testing feature -- either as part of tsql or standalone -- so
> folks who have better things to do than subscribe to this list can determine
> for themselves if their installation is happy.  And we need way better
> documentation.  Help is always welcome, btw.  :-)
> 
> This is mid-May.  A quick call to crystal_ball(struct time_t) says the
> release could be ready in September.  
> 
> I think locales.conf is toast.  That is, we don't need it anymore.  I know
> Steve Langasek is interested in this aspect, and has doubtless thought about
> it more carefully than I have.  
> 
> Bill Thompson, in case  you're listening in, you asked if it's "safe to go
> back in the water".  I'd say the answer's Yes.  But even re-writing
> tds_iconv(), which is on my todo, shouldn't interfere with your work.  Come
> on in, the water's fine.  
> 

Well... I don't personally consider libTDS stable to test in
production... Not using variable charset and not using no-GNU iconv
version... HP/UX iconv do not run at all. Mac OS X do not work
(ISO-8859-1 is not supported in Mac OS X.. strange).

Problem with variable size is sending. We compute data size to send very
lazy... 
Problem with HP/UX and Max OS X (Linux work, others not tested) is
charset names. Mac OS X recognize ISO8859-1 but not ISO-8859-1. HP/UX
has its names (like iso81, iso87, roman8, ucs2 and so on), do not have
UCS-2LE (only ucs2 and it's big endian) and also can't convert from
ISO8859-7 (iso87) to ISO8859-1 (iso81) directly... so requiring
ISO8859-A on client with ISO8859-7 on server fail...
I updated tests on configure to test standard names. This should help to
update code. IMHO our canonical name should be iconv names on machine
(so ISO-8859-1 became ISO8859-1 on Mac OS X and iso81 on HP/UX). However
if client ask for charset name machine name is returned... is this a
problem ? Is a system do not have UCS-2LE we should set a flag like
"convert UCS-2BE to UCS-2LE"... another suitable flag is pass from UCS2
(if direct conversion is not supported convert first to ucs2 and then to
destination...)

freddy77