Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]

[Philipp K. <pk...@sp...>]

>
>
>>
>>Back to the point: I use this C++ wrapper in a couple of projects. I
>>don't want to deal with more than one if not absolutely necessary.
>>    
>>
>
>I have really made up my mind but at the moment I am slightly against this API
>change because:
>1. I don't think _many_ people want to use libxml++ with a pre-existing
>Unicode string class other than Glib::ustring. I do understand that you want
>to personally but it's still hard to know what people want in general. I would
>gladly hear from other people who want to use QString with libxml++, or some
>other class.
>
I'm not using unicode at the moment, but if I wan't to add it to my 
project later I don't want to be restricted
in my choice of unicode library by the interface of libxml++. I use 
neither Qt nor glib now, so I might choose
another unicode library.

>2. I'm not sure that it's worth giving up the benefits of libxml++ being a
>shared library just so that people don't have to write utility functions to
>convert from Glib::ustring to their own string classes. In particular I'm
>scared of asking people to recompile their apps just to get minor libxml++
>implementation fixes.
>
>Again, I haven't made up my mind. And again, I'm not sure. And because I'm not
>sure I might write this up again later and ask for a vote.
>
>Not that this, or the use of glibmm, would definitely go into the unstable
>branch only anyway.
>
>  
>
Of course, one shouldn't have to recompile applications when new minor 
stable versions are released.
But I think a new major version (1.0 or whatever comes next) should use 
templates.

Philipp Krause