[freetds] status and stability
freddyz77 at tin.it
Tue May 13 15:58:38 EDT 2003
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
> 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
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
More information about the FreeTDS