You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/11/22 00:06:43 UTC
iconv features
Q to the lists;
our existing charset translation is based on iconv. Based on
that, I dropped iconv into the repository, and Jeff, Ryan and I
rearranged after that.
Looking deeply into this, I'm bringing up ICU once again. It
has several side-issues, but I believe we would be better off basing
our conversions on this package. See:
http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource
iconv ICU
flexible No, that's all it does Yes, knows locales, etc
License BSD w/advertising clause IBM Public License
Size Fairly large, w/extra&rfc1345 Absolutely huge
any<>any Yes, there is a x<unicode>y thunk No - we need to code it
portability No, this is a BSD implementation Yes - it's already ported
pure c Yup Nope, has cpp mixed in
We need to do one of two things. If we are going to use iconv, I will
adapt it for apr (especially data types and dso support!) If we are going
to use ICU, I need to write the any <> unicode <> any layer that emulates
iconv behavior. The apr'ized implementation obviously belongs in APR.
Does ICU? I don't have an answer.
Submitted for your consideration and comments,
Bill
Re: iconv features
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jeff Trawick" <tr...@bellsouth.net>
To: <ne...@apache.org>
>
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
> > We need to do one of two things. If we are going to use iconv, I will
> > adapt it for apr (especially data types and dso support!)
>
> I'm not sure what you mean by "adapt it for APR." Do you mean to make
> it more APR-like in storage allocation and interface? Do you simply
> mean to use APR portability aids (e.g., use apr_uint32_t instead of
> u_int so that it compiles everywhere)?
Right to the point... the iconv_module.c duplicates what we already do
with dso, and iconv's is limited to the freebsd .so method. Since we
already invented the wheel in apr_dso... why would we want to do so again,
this module should be stripped out of an 'apr-iconv' implementation.
One thought - the code tables are very generic, and they are a huge chunk
of the extra distribution size of the tarball. Perhaps the iconv engine
can be adapted, a module build for the particulars of a user's so (.dll)
evironment can be created, but we can set the code tables aside and let
the user download what they want, if they want. Some fundementals (we
dictate, say utf-8, ucs-2, iso-8859-1, etc) should always be packaged.
Re: iconv features
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> We need to do one of two things. If we are going to use iconv, I will
> adapt it for apr (especially data types and dso support!)
I'm not sure what you mean by "adapt it for APR." Do you mean to make
it more APR-like in storage allocation and interface? Do you simply
mean to use APR portability aids (e.g., use apr_uint32_t instead of
u_int so that it compiles everywhere)?
Thanks,
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: iconv features
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> And we might also want to consider redistributing iconv from our site, and
> teach APR how to use it if available.
+0
> Considering that iconv is already available on some platforms (didn't
> somebody say recent glibc?), it makes some sense to not ship it as
> part of
glibc 2.1.* has iconv(). This ships with RedHat 6.0.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: iconv features
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 21, 2000 at 03:21:50PM -0800, rbb@covalent.net wrote:
>
> > http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource
> >
> > iconv ICU
> > flexible No, that's all it does Yes, knows locales, etc
> > License BSD w/advertising clause IBM Public License
> > Size Fairly large, w/extra&rfc1345 Absolutely huge
> > any<>any Yes, there is a x<unicode>y thunk No - we need to code it
> > portability No, this is a BSD implementation Yes - it's already ported
> > pure c Yup Nope, has cpp mixed in
>
> I dislike the addition of cpp, for the very reasons that we have never let
> any cpp into the server itself.
Ditto.
And we might also want to consider redistributing iconv from our site, and
teach APR how to use it if available.
Considering that iconv is already available on some platforms (didn't
somebody say recent glibc?), it makes some sense to not ship it as part of
APR. Or, in other words, since APR already needs to know how to find it if
available, then we can simply say "that feature is enabled if you also
install <that> package, available form apache.org/dist/".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: iconv features
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 21, 2000 at 03:21:50PM -0800, rbb@covalent.net wrote:
>
> > http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource
> >
> > iconv ICU
> > flexible No, that's all it does Yes, knows locales, etc
> > License BSD w/advertising clause IBM Public License
> > Size Fairly large, w/extra&rfc1345 Absolutely huge
> > any<>any Yes, there is a x<unicode>y thunk No - we need to code it
> > portability No, this is a BSD implementation Yes - it's already ported
> > pure c Yup Nope, has cpp mixed in
>
> I dislike the addition of cpp, for the very reasons that we have never let
> any cpp into the server itself.
Ditto.
And we might also want to consider redistributing iconv from our site, and
teach APR how to use it if available.
Considering that iconv is already available on some platforms (didn't
somebody say recent glibc?), it makes some sense to not ship it as part of
APR. Or, in other words, since APR already needs to know how to find it if
available, then we can simply say "that feature is enabled if you also
install <that> package, available form apache.org/dist/".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: iconv features
Posted by rb...@covalent.net.
> http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource
>
> iconv ICU
> flexible No, that's all it does Yes, knows locales, etc
> License BSD w/advertising clause IBM Public License
> Size Fairly large, w/extra&rfc1345 Absolutely huge
> any<>any Yes, there is a x<unicode>y thunk No - we need to code it
> portability No, this is a BSD implementation Yes - it's already ported
> pure c Yup Nope, has cpp mixed in
I dislike the addition of cpp, for the very reasons that we have never let
any cpp into the server itself.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: iconv features
Posted by rb...@covalent.net.
> http://oss.software.ibm.com/developerworks/opensource/icu/project/index.html?dwzone=opensource
>
> iconv ICU
> flexible No, that's all it does Yes, knows locales, etc
> License BSD w/advertising clause IBM Public License
> Size Fairly large, w/extra&rfc1345 Absolutely huge
> any<>any Yes, there is a x<unicode>y thunk No - we need to code it
> portability No, this is a BSD implementation Yes - it's already ported
> pure c Yup Nope, has cpp mixed in
I dislike the addition of cpp, for the very reasons that we have never let
any cpp into the server itself.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------