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

["Cory Nelson" <phrosty gmail com>]

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
> source.

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