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.
