Move apr_xlate from apr-util to apr-iconv?

[Mladen Turk <mt...@apache.org>]

Hi,

Can we move the entire apr_xlate API from apr-utils to
the apr-iconv?

Reason for that is quite simple:
You can have apr-util independent from apr-iconv.

Thoughts?

Regards,
Mladen.

Re: Move apr_xlate from apr-util to apr-iconv?

[Erik Huelsmann <eh...@gmail.com>]

On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
> Jeff Trawick wrote:
> 
>  >
>  >> Can we move the entire apr_xlate API from apr-utils to
>  >> the apr-iconv?
>  >
>  >
>  > no; apr_xlate works just fine without apr-iconv (when system provides
>  > a suitable iconv)
>  >
> 
> It does not.

Did you read what he said? "when the system provides a suitable
iconv": Win32 does not provide such a suitable iconv. On my Linux
system (which does provide a suitable iconv), I don't need to compile
apr-iconv to use apr_xlate. I guess it does, then.

bye,


Erik.

Re: Move apr_xlate from apr-util to apr-iconv?

[Mladen Turk <mt...@apache.org>]

Jeff Trawick wrote:

 >
 >> Can we move the entire apr_xlate API from apr-utils to
 >> the apr-iconv?
 >
 >
 > no; apr_xlate works just fine without apr-iconv (when system provides
 > a suitable iconv)
 >

It does not.
On some platforms (WIN32) you can not build apr-util without apr-iconv.
At least this is a default behavior.

Of course the other option is to disable apr_xlate by default if
either iconv or apr-iconv is not found. So I wonder what is the purpose
of apr_xlate API in the apr-util at the first place if it can be
compiled out entirely.

 From my point of view, right now, the apr-util has dependency on
apr-iconv, and thus is not an stand-alone library.

Regards,
Mladen.

Re: Move apr_xlate from apr-util to apr-iconv?

[Jeff Trawick <tr...@gmail.com>]

On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
> Jeff Trawick wrote:
>  > On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
>  >>
>  >>Of course the other option is to disable apr_xlate by default if
>  >>either iconv or apr-iconv is not found.
>  >
>  > What is the problem to solve here?
>  >
>  > a) apr-util doesn't guarantee that all APIs are present on all builds
> of APR
>  > b) apr-util may depend on more than just libc+apr
>  > c) Windows build of apr-util forces you to bundle apr-iconv even
>  > though you may not care about apr_xlate, unlike the Unix build
>  >
>  > For a) and b), these are wide-spread issues, and the current state has
>  > been considered a reasonable compromise thus far.
>  >
> 
> I'm not speaking about particular features like OS or libc differences.
> Take for example xml or dbm support. For both things there are bundled
> sources inside apr-util distribution itself.

apr-iconv is relatively big
apr-iconv is not needed on many platforms anyway since system iconv is suitable
many users of apr-util can do without the feature anyway

given all that, why bundle it?

>  > For c), consider how to fix the apr-util build on Windows so that if
>  > there is no system iconv and no apr-iconv, then everything builds with
>  > appropriate feature set without somebody having to manually change
>  > some flags in apu.hw.
>  >
> 
> That's fine, I can do that.
> But in that case the xpr_xlate api either must provide a dummy char copy
> or it must be considered as an optional apr-utils component, something
> like APR_HAS_THREADS for example.

you mean, like APR_HAS_XLATE?

Re: Move apr_xlate from apr-util to apr-iconv?

[Mladen Turk <mt...@apache.org>]

Jeff Trawick wrote:
 > On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
 >>
 >>Of course the other option is to disable apr_xlate by default if
 >>either iconv or apr-iconv is not found.
 >
 > What is the problem to solve here?
 >
 > a) apr-util doesn't guarantee that all APIs are present on all builds 
of APR
 > b) apr-util may depend on more than just libc+apr
 > c) Windows build of apr-util forces you to bundle apr-iconv even
 > though you may not care about apr_xlate, unlike the Unix build
 >
 > For a) and b), these are wide-spread issues, and the current state has
 > been considered a reasonable compromise thus far.
 >

I'm not speaking about particular features like OS or libc differences.
Take for example xml or dbm support. For both things there are bundled
sources inside apr-util distribution itself.

 > For c), consider how to fix the apr-util build on Windows so that if
 > there is no system iconv and no apr-iconv, then everything builds with
 > appropriate feature set without somebody having to manually change
 > some flags in apu.hw.
 >

That's fine, I can do that.
But in that case the xpr_xlate api either must provide a dummy char copy
or it must be considered as an optional apr-utils component, something
like APR_HAS_THREADS for example.

Regards,
Mladen.

Re: Move apr_xlate from apr-util to apr-iconv?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:01 PM 7/8/2005, Branko Čibej wrote:

>APR is not just a utility for httpd. Subversion uses it and relies heavily on apr_xlate, and doesn't use apr_iconv on Unix.

However it does trust iconv.  Just to clarify.

We need something :)

Bill

Re: Move apr_xlate from apr-util to apr-iconv?

[Branko Čibej <br...@xbc.nu>]

Mladen Turk wrote:

> I just browse the source code for the httpd and in 99% there is a
> single need for apr_xlate API, and that is to convert from
> ISO-8859-1 to EBCDIC if someone is using IBM at the first place.

APR is not just a utility for httpd. Subversion uses it and relies 
heavily on apr_xlate, and doesn't use apr_iconv on Unix.

-- Brane

Re: Move apr_xlate from apr-util to apr-iconv?

[Jeff Trawick <tr...@gmail.com>]

On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
> 
> I just browse the source code for the httpd and in 99% there is a
> single need for apr_xlate API, and that is to convert from
> ISO-8859-1 to EBCDIC if someone is using IBM at the first place.

or Fujitsu

> So IMHO we can write a simple converter for that, and get rid
> entirely of iconv dependency from apr-util.
> Someting like apr_ascii_to_ebcdic should do thought.

something so simple would work for HTTP protocol data but not bodies;
the body translation is useful on more than just EBCDIC machines;
check out "Russian Apache" for an extreme example (an incredible
amount of work put into patches for Apache 1.3 to translate body
data); no EBCDIC anywhere close

> If someone wish to use the translation mechanism, well, the
> there is apr-icov project that should in that case provide
> the full apr_xlate api.

So where does system iconv fit in?  It is an important feature to be
able to use system iconv when available, since translation plug-ins
which users have collected for their data in the past will work with
apr-util apps as well.

> Only mod_charset_lite uses the full capability of iconv stuff,

(as far as Apache is concerned, as far as I know)

> so what's the point to link the apr-util with the
> iconv/apr-iconv anyhow?

if system iconv doesn't exist or isn't good enough

Re: Move apr_xlate from apr-util to apr-iconv?

[Mladen Turk <mt...@apache.org>]

Jeff Trawick wrote:
>>>>Can we move the entire apr_xlate API from apr-utils to
>>>>the apr-iconv?
>>>
>>>no; apr_xlate works just fine without apr-iconv (when system provides
>>>a suitable iconv)
>>>
>>
>>It does not.
> 
> 
> you misread my statement, but that isn't really the point...  (I was
> trying to convince you that the current arrangement makes a lot of
> sense on some platforms...)
>

I just browse the source code for the httpd and in 99% there is a
single need for apr_xlate API, and that is to convert from
ISO-8859-1 to EBCDIC if someone is using IBM at the first place.

So IMHO we can write a simple converter for that, and get rid
entirely of iconv dependency from apr-util.
Someting like apr_ascii_to_ebcdic should do thought.

If someone wish to use the translation mechanism, well, the
there is apr-icov project that should in that case provide
the full apr_xlate api.
Only mod_charset_lite uses the full capability of iconv stuff,
so what's the point to link the apr-util with the
iconv/apr-iconv anyhow?


Regards,
Mladen.

Re: Move apr_xlate from apr-util to apr-iconv?

[Jeff Trawick <tr...@gmail.com>]

On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
> Jeff Trawick wrote:
> >
> >>Can we move the entire apr_xlate API from apr-utils to
> >>the apr-iconv?
> >
> > no; apr_xlate works just fine without apr-iconv (when system provides
> > a suitable iconv)
> >
> 
> It does not.

you misread my statement, but that isn't really the point...  (I was
trying to convince you that the current arrangement makes a lot of
sense on some platforms...)

> On some platforms (WIN32) you can not build apr-util without apr-iconv.
> At least this is a default behavior.
> 
> Of course the other option is to disable apr_xlate by default if
> either iconv or apr-iconv is not found. 

That's what happens on Unix.

> So I wonder what is the purpose
> of apr_xlate API in the apr-util at the first place if it can be
> compiled out entirely.

It is not unusual in the apr/apr-util project for there to be APIs
which are not available if some underlying feature is missing, or if
apr/apr-util is built in a special manner.
 
>  From my point of view, right now, the apr-util has dependency on
> apr-iconv, and thus is not an stand-alone library.

s/stand-alone library/library which just depends on bare minimum
system libraries and libapr/

On Unix at least, this has been the choice of the packager.

-/-

What is the problem to solve here?

a) apr-util doesn't guarantee that all APIs are present on all builds of APR
b) apr-util may depend on more than just libc+apr
c) Windows build of apr-util forces you to bundle apr-iconv even
though you may not care about apr_xlate, unlike the Unix build

For a) and b), these are wide-spread issues, and the current state has
been considered a reasonable compromise thus far.

For c), consider how to fix the apr-util build on Windows so that if
there is no system iconv and no apr-iconv, then everything builds with
appropriate feature set without somebody having to manually change
some flags in apu.hw.

Re: Move apr_xlate from apr-util to apr-iconv?

[Jeff Trawick <tr...@gmail.com>]

On 5/30/05, Mladen Turk <mt...@apache.org> wrote:
> Can we move the entire apr_xlate API from apr-utils to
> the apr-iconv?

no; apr_xlate works just fine without apr-iconv (when system provides
a suitable iconv)

> Reason for that is quite simple:
> You can have apr-util independent from apr-iconv.

if a system has no suitable iconv and you don't want to drag apr-iconv
around with apr, maybe there should be a configure option to disable
the API; on Windows, you do something like set APR_HAS_XLATE to zero
in apu.hw (???) and apr_xlate is disabled, and thus the dependency for
apr-iconv has vanished