Re: [xml] libxml2 API crazy?



I agree with everything except ... I still use plain old C ... I just make my wrappers manage a lot of the underlying things.  I would moderate your description a little -- these are low-level routines.  It would be like comparing C to C++ -- it is not that C is so limited, it is for a different purpose.  It is faster and more efficient -- and clumsier to work with. 

To each his own.  I probably should not have gotten into this thread except I have used this library for so long and it has been so good to me, I hated to see it "trashed" -- of course it can be better, but it is free.  When I needed some improvements, I made them and submitted them and Daniel incorporated them.  Cool.  If you are willing to do the work ... you can have whatever you like.  It might be nice someday to have a place for everyone to share their wrappers.  Mine (IMHO) are unique and useful.  I am sure others are as well.

I WOULD be willing to put some time into making a wrapper suppository ...


Eric

On 5/3/2013 6:21 PM, Sam Varshavchik wrote:
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.

_______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml gnome org https://mail.gnome.org/mailman/listinfo/xml

-- 
Eric S. Eberhard
VICS
2933 W Middle Verde Road
Camp Verde, AZ  86322

928-567-3727  work                      928-301-7537  cell

http://www.vicsmba.com/index.html             (our work)
http://www.vicsmba.com/ourpics/index.html     (fun pictures)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]