Hello,
As you perhaps know, I am currently porting libcurl to OS400.
Unlike TPF (which seems to be the target environment for conversions),
the native character code on OS400 is not fixed: it can be any variant
of EBCDIC (they are several). Depending on the country for which the
machine is configured, another variant is used by default. Thus machines
located in US, FR or CH all have different default character encodings.
Moreover, an application may change dynamically its own current "native"
character set...
 
This leads in the following situation:
_ We have libcurl char/string constants, their charset is established
during compilation of libcurl (once compiled, it is fixed),
_ The character set of the network (Something like ASCII!)
_ The current "job" (i.e.: native) character set, that may even change
between 2 calls to libcurl entry points.
 
Those may not be fully compatible. Using the current conversion feature
of libcurl (fixed native character set) only allows to prepare libcurl
for a particular native character set other than ASCII.
Requiring an OS400 application using libcurl to use conversion callbacks
systematically seems to me an unacceptable solution.
 
So I need to extend the conversion feature. I have some alternative
approaches for this purpose (all of them requiring additional entry
points) and I request your advice on this subject.
 
1) Make the native character set a variable, settable by an API. This is
simple, but may result in converting from/to a wrong character set if
converted data has been latched prior to a charset change.
2) Provide additional "wrapper" entry points mimicking the current ones,
but allowing character sets to be specified for character arguments.
This is much eavier, but more reliable, though probably useless on a
non-OS400 machine.
 
Thanks in advance for you ideas.
Patrick
Received on 2007-06-28