httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: iconv features
Date Tue, 28 Nov 2000 18:54:17 GMT
From: "Jeff Trawick" <trawickj@bellsouth.net>
To: <new-httpd@apache.org>
>

> "William A. Rowe, Jr." <wrowe@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.




Mime
View raw message