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)
|
