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.
The work so far (from the summer, and resuming from this past week) is now available in the libgdata repository in a branch "gxml". There shouldn't be any real need to use that right now, and there's actually a small increase in the total lines of code after porting, due to trying to preserve assumptions from libxml2 to minimise changes to behaviour for now.
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.
Keine Kommentare:
Kommentar veröffentlichen