httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: OS/390 specific directory in 2.0
Date Wed, 22 Mar 2000 23:48:21 GMT
> Codepage translation is an APR issue.  Please look at the archives for a
> few months ago, I posted the API that APR will be using for codepage
> conversions.  This removes the EBCDIC issue from Apache.

(Gee... This is too darn long.  Shouldn't such a post be rejected
automatically?)

Yes, I remember the iconv() wrapper discussion.  That was right about
when I started lurking.  Have you gotten very far on the implementation?

My feeling is that moving the actual translation to APR is o.k., but
that it hardly removes the EBCDIC issue from Apache.  The possibly
interesting aspects of translation are choosing the source and dest
code pages and knowing when to translate.  Neither of these are for
APR to deal with.  APR is left with doing some fairly tedious
translation state management (if you handle non-SBCS) or indexing an
array that was built when the source and dest code pages were chosen.
As I recall, you chose the tedious interface (iconv()-like) with the
trivial level of function.  If we only need the trivial level of
function, why waste time mimic-ing iconv()?  Let's refactor what we
have, not bother investing in an implementation we don't need now, and
be assured that if the requirements change down the road it is easy to
"fix" then.  After all, there won't be much to "fix."

It would be nice to *use* iconv() in the APR codepage translation
support to build a translation array at the time the source and dest
code page were chosen.

My own experiences with iconv(), for what they're worth:

. various product code I have dealt with uses iconv() religiously for
translating non-SBCS when needed (Asia) but for the normal (?) case
uses iconv() at init time to build an array; it is too expensive to go
through the function calls compared with translating "manually" from a
prebuilt array; just using iconv() and managing the caller side of the
translation state and doing the required return code feedback handling
is expensive/complex enough that there tend to be two paths through
the caller code

. I started writing an iconv() wrapper myself for some code I
wrote/maintain.  It seemed like a neat project; I "needed" iconv() on
some platforms that didn't provide it; I made some progress; it
wasn't hard but there were tedious details to handle if I wanted to do
it properly; I didn't really need it; none of my users complain that I
don't use iconv() :)

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message