Still working a lot on the libxml2 changes for 2.6.0 . So far the feedback I got was good on the new API, I will need to make docs, yes this deseperately need better docs, but at least like for the xmlReader API, I have API I feel comfortable documenting. Getting review and patches, someone posted some code implementing something like the xmlReader but working on the tree, Considering that a lot of people seems to have troubles simply walking a tree structure, this may be useful. The negative part is of course the library size. Apparently some people have a hard time with this for desktop use while other are using libxml2 on embedded system, anyway I spent most of the week-end modularizing the library further, there is now a configure flag --with-minimum, which turn off everything possible (including serialization, reader, and even the old SAX1), in which case the library is around 170Kbytes. One of the gain I expected to have in 2.6.0 was to drop the old DocBook SGML parser from the default library configuration, it was intended only as a way to help convert document though xmllint and xsltproc, but apparently scrollkeeper still uses it. Dunno how to best proceed, at the moment the docbook parser simply calls the XML parser so if document were not converted it may fail. Of course I'm sure this is gonna be a pain. since I really don't want a libxml2.so.3 or a libxml3 at the moment, I may have to reintegrate that code ... damn

I'm in the process of making changes to the error reporting in libxml2, last error informations will be availble either globally (per-thread) or within the parser context. Programmers will be able to either gather the structured informations from the synchronous call-back that is already available, or asynchronously when the API call returns. It's like a Gerror but with far more specialized informations. While a think it's a great enhancement, it's a PITA to do, going over the full code trapping the callback and making structured calls instead, sigh...

It's interesting to see the reactions from the libxml2 list to some geeky topics like how C code get optimized, performance, or pure POSIX conformance. There is an interesting talent pool, I find myself asking more and more and really appreciating the quality of the feedback. To me that's one of the main interest of developping in the open-source, you get direct contact with your best users, and the users can be in direct contact with the developper. As the project is evolving, trust is built, information, skills and process get integrated, a good project will distill the best from the talent available, this is enjoyable and if successful bring quality code (and docs) as a result.

Decided to unsubscribe from the OASIS XML-Dev mailing list, I already getting enough mail, and the constant pressure affects my mood, I tend to overreact. The best I can do is to get off list where I'm annoyed because I can become annoying.