db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Client decoding of server Fdoca data, which direction do we want to go?
Date Fri, 10 Feb 2006 13:55:27 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Knut Anders Hatlen wrote:
>
>>Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:
>>
>>Hi Kathey, if I understand you correctly, your question is: "Can we
>>assume that the Derby client driver is talking to a Derby network
>>server?" If we answer yes to that question (which I think we should),
>>I would go for option 1 as long as the network server always sends
>>Fdoca as UTF-8.
>>
>>In my opinion, there is one additional question we need to ask: Do we
>>always want the network server to send Fdoca as UTF-8, or should it
>>sometimes use another encoding? Issues with performance or
>>functionality might make us want to support other encodings. For
>>instance, UTF-16 is a much better choice for Chinese text because you
>>need only two bytes per character instead of three bytes per
>>character. If we think it's likely that we are going to support more
>>encodings, option 2 sounds like a better choice.
>>
>>  
>>
> That's a good point.   I have no plans to do that kind of work but
> perhaps someone else has an interest in it.  I'd say if it is not
> planned for the near term we go with option 1.  The existing untested
> code is only likely to become more broken, confusing, and deceptive over
> time.

Agreed. We probably have to rewrite most of it anyway if/when we're
going to add support for more encodings.

-- 
Knut Anders


Mime
View raw message