[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Adding a build/configure *option* to use ICU converters
- From: Daniel Veillard <veillard redhat com>
- To: Mark Rowe <mrowe apple com>
- Cc: xml gnome org
- Subject: Re: [xml] Adding a build/configure *option* to use ICU converters
- Date: Thu, 27 Sep 2007 09:08:58 -0400
On Thu, Sep 27, 2007 at 05:48:00PM +1000, Mark Rowe wrote:
>
> On 26/09/2007, at 18:33, Daniel Veillard wrote:
>
> >I don't see why your patch shouldn't be applied and yes adding the
> >option
> >on configure would be sensible (as long as it's off by default).
> >Also I would
> >really prefer if Unixes didn't switched it on when distributed as
> >part of
> >the OS to maintain a predictable behaviour on all similar platforms.
>
> 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.
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/
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]