Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sun, 2003-09-28 at 09:41, Daniel Veillard wrote:
> On Sun, Sep 28, 2003 at 02:18:02AM -0400, Havoc Pennington wrote:
> > At this point I think we're in agreement, if you're saying that as long
> > as I am using expat I'm sufficiently conformant.
> 
>   I want to understand why you would use expat instead of libxml2
> except for the sole argument of driving me nuts, which apparently 
> you take a lot of fun doing...unless there is an hidden reason.

I do have config-loader-libxml.c, but the reason it isn't the default is
that "make check" didn't pass with it. I filed a bug and test case about
out-of-memory handling that you fixed, so in theory make check might
work now (I think a bit more code needs writing in
config-loader-libxml.c still). In any case, XML is just used in the
daemon (an executable) rather than a lib so implementation can be
changed whenever. 

The reason the daemon can use multiple XML libs is that a) it's really
easy to allow multiple and b) I don't want someone to not use the
package because I chose the wrong dependency. It's intended to be in the
freedesktop.org suite and fontconfig also has the libxml-or-expat thing.

>   I just checked, by disabling all optional options of libxml2
> I get to around 250K of code. I could easilly trim this down a lot
> by removing all the validation code, and tree modification code.
> Assuming I do this and allow to generate a libtinyxml2 along
> libxml2:
>     - would you use this
>     - would you back-up this change at the Red Hat distro level
>       and avoid any objection I may get in the process.
> I think this option would be useful for my user base on embedded
> systems. This would duplicate code but not API/implementations/debug
> existing APIs to build a tree or stream with the reader or SAX1/2
> interfaces would be intact (except for the validation capabilities).

I think a libtinyxml2 with expat-level functionality would be
interesting to explore, but _please_ don't API/ABI-freeze it until it's
been banged on and reviewed for several months and people have actually
used it. Perhaps it should be on a branch, I don't know.

Note that the API can't share symbols with main libxml if it's used by
any libraries, because if there are shared symbols you can't use both
libxml flavors in one process. For example GLib can't start using
symbols that conflict with libxml because then apps linking to libxml
would break. Anyway, it's an idea worth exploring but I don't know
whether it's a good idea, the details would have to be worked out.

Havoc