During the summer, to exercise the GXml API, I wrote a series of patches for libgdata, which uses libxml2 nodes a lot. I ran into an issue where libgdata's test suite requires Internet access to communicate with Google's servers, and while in Germany, I didn't have reliable Internet access, making testing my patches difficult. However, now that the start of this school semester is behind me and things are settling into a routine, I've finally been able to investigate issues I had with my patches. Here are some related thoughts.
- memory management changes: libxml2 often returned allocated strings that it wanted the user to free. GXml often returns allocated strings that it does not want the user to free, as the relevant object (e.g. an Attr) owns it (e.g. the Attr's value). After directly substituting APIs, this was causing random memory corruption, where I was freeing data prematurely or twice. I still need to go through and identify all the free statements to be removed, but for now, I'm using g_strdup () to wastefully create a copy that the pre-existing code can act upon as it used to.
- longer function names: because GXml is written in Vala and uses namespaces and less cryptic naming in general, the function names are longer than in libxml2, like gxml_dom_element_get_attribute as opposed to xmlGetProp. So, clearer functions, but more typing.
- NULL return values: libxml2 often returned NULL, like when an attribute wasn't set, but the DOM Level 1 Core spec wants an empty string "" to be returned instead. Currently, I have a couple libgdata wrapper functions for situations like this that return NULL if they can determine that an attribute wasn't set in GXml, rather than "" itself, but taking another look at how libgdata handles unset attributes and such will be worth while.
Once libgdata is fine, I'll be releasing a porting guide with advice for those interested in using GXml in the future
introspection and javascript
I've received some questions about using GXml with JavaScript already, so I'm going to work on introspection this week before I'm done with libgdata. Then I can provide some examples.
new release?
The last official release has no name space support (git does) and is lacking recent bug fixes. I'll try to push a new release out this weekend for people wanting to play with it now. If that goes well, I might do a small release every other week.
Libxml2 often returns NULL for failure because memory allocations failed. (E.g. the system used ran out of virtual memory.) In those cases, you can't return "". strdup("") is an allocation and is bound to fail.
ReplyDeleteYah, without another option, GXml will return NULL in those cases as well :) When an attribute just isn't set, though, xmlGetProp returns NULL while we return "".
ReplyDeletePlease review Bug# 663367 - Add Autotools support.
ReplyDeleteI filed it and attached a patch. I'm ready to push to master if this is approved.
I didn't touch any about WAF build, but I've able to get GIR output from sources and want to configure to correct installation.
I have an issue on GIR -> typelib, compilation due to GXML nested namespaces (see at Bug #576327). I would like to fix it by:
a) Include in the name Dom in the class name (as made by GStreamer)
b) Extend namespace from GXml to GXmlDom
Hi Daniel.
ReplyDeleteSorry for not getting to the patch sooner. Do you mind if it's the first thing I review tomorrow morning? This semester of my masters has been very busy and so I haven't gotten to do as much as I'd like, but I can give you my entire morning tomorrow :)