apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: apr-iconv 1.0
Date Thu, 31 Mar 2005 11:27:16 GMT
William A. Rowe, Jr. wrote:
>>
>>Well, I'm interested if the final product will not depend on a
>>hundred or so separate .dll's for each and every charset, and
>>if apr_util will not depend on apr_iconv.
> 
> I'd see that as advantage as well.  I understand loadable
> modules for complex translations, but not for tables.
>

I would like that we first resolve the static linking of
apr-iconv to apr-utils, and using apr_dso_* for
apr_iconv functionality. For me that is the major issue.
Other is that reimplementing either
Konstantin's iconv 2.x as part of apr_iconv would lead to
the same problems. Either we will build something of our
own, and take responsibility for that, or we will build a
wrapper against what ever native iconv implementation
there is. Having duality is IMO a bad thing.

>>Also I think we should consider using
>>MultiByteToWideChar/WideCharToMultiByte on windows as
>>an option to apr_xlate if iconv is not present.
> 
> See my post on this very point.  The API does not lend itself
> whatsoever to streaming data.  Most every APR application is
> dealing with streamed text so this isn't really a useful option.
>

I'm sure we can think of something, but if you say that we
can not use native WIN32, then we could at least offer the
option to use gnu-iconv for win32 builds as well, or any other
iconv-api library.
Like said, I think that we should either build our own
implementation of iconv functionality, or just build a wrapper
over existing one.

So, I see the future of apr-iconv as ASF implementation of
iconv, with iconv abstraction layer moved to apr-utils, that
will use apr-iconv, as just one of the flavors of iconv api.

Regards,
Mladen.

Mime
View raw message