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

[Daniel Veillard <veillard redhat com>]

On Thu, Sep 27, 2007 at 07:35:53AM -0700, Cory Nelson wrote:
> 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.

  Maybe. I still perceive ICU initialization as something really heavy.
If you have data to prove me wrong I will be glad to revise my opinion :-)
In the meantime I really prefer not having to rely on ICU for libvirt
operations on normal configuration. If Apple really want to go that way
I won't be able to avoid this, but I would rather not see this unless
the serious drawback I perceive can be cleared up.

  Also note that the viewpoint I got was:
   "we want to build against ICU because we don't want to depend on iconv"

and I'm precisely of the opposite opinion, I don't want to depend on ICU.
Iconv is part of the posix standard ICU is not. Iconv is maintained by the
community, I perceive ICU as being primarily supported by IBM.
To me ICU is to iconv what xerces is to libxml2, for coherency I really
prefer to see libxml2 link to iconv than to ICU.

I'm okay to leave the choice you ask for but I have reasons I want libxml2
to link to iconv by default instead of ICU. Some are technical, some are
more fuzzy, others are just plain support issues. Iconv is part of the
platform core libraries on Linux, it's standard, ICU is a separately
maintained library, I have no clue who to poke if needed or how much it
will impact parsing.

  Put that big brick underneath and I have no garantee that the way I
perceive libxml2 efficiency will be the same as other users will. Yes,
I'm afraid of serious bloat and inefficiency, first grabbing the
C++ stack when not needed as libxml2 is pure C, second very large table
initialization and memory footprint, third APIs which seems to internally
depend on non UTF-8 strings, lot of duplication for things which are
coming from the OS on my platform, and lot of manipulation that libxml2
does not need. On the other hand iconv is standard, does just what I need
and is just plain part of the OS. So by default no no no I don't want
libxml2 to depend on ICU, really !

  You want your choice, I want the best for my average user and minimal 
support hassles !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/