GXml, libgdata, and introspection


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

Dieses Blog durchsuchen


#Technology #GNOME gnome gxml fedora bugs linux vala google #General firefox security gsoc GUADEC android bug xml fedora 18 javascript libxml2 programming web blogger encryption fedora 17 gdom git libgdata memory mozilla open source serialisation upgrade web development API Spain design emacs evolution fedora 16 fedora 20 fedora 22 fedup file systems friends future glib gnome shell internet luks music performance phone photos preupgrade tablet testing yum #Microblog Network Manager adb art automation bash brno catastrophe containers css data loss deja-dup disaster emusic errors ext4 facebook fedora 19 gee gir gitlab gitorious gmail gobject google talk google+ html libxml mail microsoft mtp namespaces nautilus php picasaweb podman ptp resizing rpm school selinux sms speech dispatcher systemd technology texting time management typescript uoguelph usability video web design youtube #Tech Air Canada C Empathy Europe GError GNOME 3 GNOME Files Go Google Play Music Grimes IRC Mac OS X Mario Kart Memento Nintendo Nintendo Switch PEAP Selenium Splatoon UI VPN Xiki accessibility advertising ai albums anaconda anonymity apache apple ask asus eee top automake autonomous automobiles b43 backup battery berlin bit rot broadcom browsers browsing canada canadian english cars chrome clarity comments communication compiler complaints computer computers configuration console constructive criticism cron customisation dataloss dconf debian debug symbols debugging design patterns desktop summit development discoverability distribution diy dnf docker documentation drm duplicity e-mail efficiency email english environment estate experimenting ext3 fedora 11 festival file formats firejail flac forgottotagit freedom friendship fuse galaxy nexus galton gay rights gdb german germany gimp gio gjs gnome software gnome-control-center google assistant google calendar google chrome google hangouts google reader gqe graphviz growth gtest gtg gtk gvfs gvfs metadata hard drive hard drives hardware help hp humour identity instagram installation instant messaging integration intel interactivity introspection jabber java java 13 jobs kernel keyboard language languages law learning lenovo letsencrypt libreoffice librpm life livecd liveusb login macbook maintainership mario memory leaks messaging mounting mouse mysql netflix new zealand node nodelist numix obama oci ogg oggenc oh the humanity open open standards openoffice optimisation org-mode organisation package management packagekit paint shedding parallelism pdo perl pipelight pitivi privacy productivity progress progressive web apps pumpkin pwa python quality recursion redhat refactoring repairs report rhythmbox sandboxes scheduling screenshots self-navigating car shell signal sleep smartphones software software engineering speed sql ssd synergy tabs test tests themes thesis tracker travel triumf turtles tv tweak twist typing university update usb user experience valadoc volunteering vpnc waf warm wayland weather web apps website wifi wiki wireless wishes work xinput xmpp xorg xpath
Powered by Blogger.