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



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]