DJ> I can't say I understand this argument very well or at all, however I'm
DJ> finding Roman's side more convincing.

Yes it is, in many cases, especially when you stay in the Java system.
Let's say you have a GUI in Java. But this situation changes quickly
when you read strings from HTTP, from other JDBC driver or from any
other system that does not use Unicode, and believe me, there are
many.

DJ> I was under the impressions that all Java strings were unicode, and there
DJ> was no choice in this.  Therefore I thought the only problem was how to
DJ> send unicode strings to firebird, depending on the firebird db and column
DJ> char sets.

With the current solution it will work only for db character sets not
for columns.


DJ> I think problems of properly getting national characters into
DJ> firebird from sources such as web pages should not be the firebird driver's
DJ> problem. 

From my point of view, it is much easier to disable this feature in
the JDBC driver with switch rather than make conversion for *every*
string in the source code.

DJ> From this point of view I don't really understand why you should
DJ> need to specify any client encoding, since I thought it was always unicode.

Because only Java is unicode. You have to make 8 bit characters from
16 bit characters. That is only possible if you specify which unicode
characters are valid in that encoding (which are those Unicode 256
character that can be converted.)

DJ> A new, really simple, example might help me.

Actually Java strings are Unicode. But in many cases you may want use
a different interpretation: you store only 8-bit characters in
strings. (Even the new Regexp package in JDK 1.4 works well only with
ISO-8859-1...) Because your task is not to perform state-of-the-art string
manipulation in Java, but rather to read a string from a source, store
it in Firebird, and write it back to a different destination.

DJ> In any case, when can I release a binary version of the driver?

DJ> Thanks
DJ> david jencks