Re: [xml] Adding a build/configure *option* to use ICU converters

On 9/27/07, Daniel Veillard <veillard redhat com> wrote:
On Thu, Sep 27, 2007 at 05:48:00PM +1000, Mark Rowe wrote:

I'm not sure I understand this argument.  Other than the character
sets supported by the library, there should be zero difference between
functionality when using ICU or iconv.  The character sets available
to iconv appears to be very platform-dependent as well.  A comparison
of two Debian machines I have at hand shows that one has over 1150
encoding aliases available to iconv, while the other only has 950.  On
two Macs that I have in front of me running different versions of Mac
OS X, one has 460 and the other 400.

Could you clarify what you mean by this?  I'm not advocating that ICU
be the default, I'm just curious why you feel vendors should not use
it if it is present.

  Very simple, I don't want to be perceived as depending on ICU. I don't
want all apps depending on libxml2 to depend (indirectly) on ICU.
I also know that iconv memory footprint at runtime is near neglectible,
when I looked at ICU (a long time ago admitedly) it really wasn't looking
that way. I don't want a simple xmllint of a file using latin character to
drag megabytes of memory just because you though it was a good idea to
link to ICU 'because it is available'. The end result will be 'libxml2
is a memory hog' and people will just don't look at why this happened
just on a given platform.
  If there is any risk of this, I prefer to not put any patch in the

I vehemently disagree with this line of thinking.  Pandering to idiots
so that you get a better review on their invalid benchmarks is a
horrible, HORRIBLE, idea.  Idiots will be idiots, regardless of what
you do.  It's the informed people which you should care about - and to
them, choice will always better.

Cory Nelson

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]