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

[Murray Cumming <murrayc usa net>]

Stefan Seefeld <seefeld sympatico ca> wrote:
> Murray Cumming wrote:
> 
> > 1. I don't think _many_ people want to use libxml++ with a pre-existing
> > Unicode string class other than Glib::ustring.
> 
> why are you so GNOME [*] centric ? There is more to life than that !

I am not being GNOME-centric. Glib::ustring will be available for general
non-GTK, non-GNOME use. I don't know of any other C++ unicode string class
that is not tied to a GUI toolkit. Please try to read my responses instead of
just repeating your vague accusation that my involvement with GNOME is somehow
a disadvantage to you.

> > 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.
> 
> no, the issue is a bit more involved.

Could you tell us more?

> Of course, having to convert
> between two unicode string types is a major annoyance, especially if we
> are talking about performance.

Yes, performance is the only issue that I can think of. Luckily I can sidestep
that with my usual "profile-before-optimising" argument.

> But another issue is a new (and totally unnecessary) dependency to
> unrelated libraries such as glibmm (and all the dependencies that will
> drag in) !

glibmm requires only glib. That's really not very much, particularly as every
single linux and solaris installation will have glib installed in the near
future, and there's a high chance that the same will be true of glibmm. Given
your slightly irrational fear of glib I'm surprised that you don't object to
our use of pkg-config too as that was also produced by people involved with
GNOME.
 
> > In particular I'm
> > scared of asking people to recompile their apps just to get minor
libxml++
> > implementation fixes.
> 
> I understand. But I still think this is a non-issue, as I don't expect
> libxml++ to contain much code.
> It's just a wrapper around libxml2 after
> all.


We are still fixing bugs in implementation. Can you predict when there will be
no more implementation bugs? Personally, I can't predict the future and I
don't plan as if I can.

> But then, may be this discussion just reveals a major difference in
> our respective vision of what libxml++ should be all about. I can see
> you not wanting to drag in the drawbacks genericity means to you if all
> you ever want to do with libxml++ is inside GNOME projects. But then
> *please* make it clear that libxml++ is intended for a restricted
> audience.

See above. I don't think there is any reason for you to believe this.


Murray Cumming
murrayc usa net
www.murrayc.com