Nikita Churaev writes:
I'm glad that the layer of abstraction helped you personally, but libxml2 really needs to be usable as-is and the GObject wrappers (GXml, etc.) should just be trivial things. If wrappers are made but the libxml2 itself is kept in this current insane state, it'll just become more and more entangled, so no one will step up to maintain it if the current maintainer leaves and it will die. XML is the most important data format in the world, in fact, the official data format of planet Earth, if GNOME is to survive, it should better have a well-documented, maintainable and sane XML API. Without an XML API usable by normal people who value their time, GNOME will surely die.
I think that, for what it is, namely a C API library, libxml2 is quite usable, and the API is clean, and logical.
But I wouldn't use it directly for large scale application development. The reason being that, at least in my corner of the world, C is simply not suitable for developing large, complicated applications. Those beasts are written, pretty much exclusively these days, in C++. And libxml2 simply lives on a different, lower level, than C++, and you need higher level C++ bindings to be productive, so I've written my own bindings: http://www.libcxx.org/xml.html
If I wanted to write out a simple "Hello world", in XHTML, more or less:
auto doc=x::xml::doc::create();
doc->writelock()->create_child()->element({"html"})->element({"body"})
->element({"p", {
{"style", "font-family: courier new"}
}})->text("Hello")->parent()->create_next_sibling()
->element({"p", {
{"style", "font-family: arial"}
}})->create_child()->text("world!");
doc->readlock()->save_file("filename.xml");
Doing the equivalent directly using libxml2's native API calls probably take
a little bit longer than eight lines of code, if you also need the results
to be: 1) thread safe, and 2) take care of releasing all
memory/objects/handles/etc (thread safety is not a factor in this particular
case, but, if something was going on in that area, this would be thread
safe).
This creates a simple XML document, using libxml2's tree API, and saves it. Of course, you can just dump a literal string into a file directly, but that's besides the point.
Once code grows besides a certain size, the additional burden of releasing all handles, and resources, to avoid leaking memory, implementing thread safety, and other tedious tasks, just adds to the overhead. The above example uses reference-counted objects, and once all variables and objects go out of scope, all libxml2-obtained resources will get released, and I'll have better things to worry about, with my time, than that.
The native C-based libxml2 API is just not feasible for non-trivial tasks. You need to keep track of all the objects/memory that it creates for you. You need to make arrangements for implementing everything in a thread-safe manner. And I really don't really want to spend a lot of time doing that, so libxml2 native API is just not enough, but it's perfectly fine as a foundation for more higher-level API abstractions, and I don't think there's anything wrong with that.
Attachment:
pgp4myU9Pgx2P.pgp
Description: PGP signature