FreeTDS Development Group

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

All, 

There are two remaining character set issues.  I want to explain my
strategy here, in case someone has a better idea.  

1.  Server charset names.  The vendors use their own naming convention. 
Sybase for example uses "iso_1" to for (I think) ISO-8859-1.  To convert
these names to GNU iconv names, we can continue to use
tds_canonical_charset_name().  I've mapped the obvious Sybase ones, which
should get us started.  If someone wants to take a crack at Microsoft's
list, I'd be happy to add those.  We're going to need it for per-column
conversion.  

2.  Systems with non-GNU iconv.  If your libc (or whatever) includes an
iconv implementation and you link to that instead of GNU's, FreeTDS won't
have a mapping of the server's character set names to names suitable for
your iconv.  

I've thought about problem #2, and there's no low-maintenance solution. 
It's the client charset name problem all over again: how to anticipate and
cope with every variation of, say, "UTF-8"?  I've decided that as far as
I'm concerned, FreeTDS is free software, and we should take a free
software approach.  IMO, we can offer two:

A.  Use GNU libiconv, or  
B.  patch sybase_character_sets.h

That's it.  No files, no freetds.conf entries, no environment strings. 
We'll completely support open systems, and make it possible for users of
closed systems to augment our capability on them.  

Rationale
---------

This is the kind of problem that's better to fix "in house" than to
document for an admin to puzzle through.  It's also a distraction from our
main goals, particularly given that a free solution exists.  

It's no harder to patch the .h than to add a line to freetds.conf
(although it does mean recompiling).  In either case, one first has to
master the issues, a non-trivial undertaking, and then come up with an
accurate mapping.  That's a lot of work, and it would be good if others
could benefit from it.  

If we handle the mapping in freetds.conf (or locales.conf), the problem is
no less daunting, but there's no real incentive to share the fruits of
that labor.  After all, the problem is solved and subsequent releases of
FreeTDS will presumably rely on the same entry.  Meanwhile, we're left
with still another bit of code to maintain, support, and document.  

On the other hand, requiring a patch to a header file creates a strong
incentive.  Sending us a patch avoids re-patching for subsequent releases.
 And for redistribution, the LGPL kicks in.  If, say, HP were to
redistribute FreeTDS for Digital's Unix (whatever it's called these days),
they'd be forced to fix the code to make it work, and to publish their
work.  

Your humble maintainer, 

--jkl