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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
