Coder's Log

Some weeks back, Marc-Andre told me that it will probably be helpful for potential contributors if I could write a blog post explaining how new information could be added to libosinfo (the library Boxes relies on for information on various operating systems and their installer medias) so here I'm doing just that. Currently there are two types of information you can add, devices and operating systems. Usually, it'll be the latter that you'd want to add (e.g your favorite OS just made a new awesome release and you want libosinfo to know about it) but for the sake of completion, I'll describe both. Libosinfo keeps its information database in a bunch of XML files. Although theoretically there could be just one XML file but that would have to be really huge and therefore will be very hard to edit/maintain so we keep each OS distro and device class in its own XML file. Libosinfo recursively traverses the following locations, assuming application let libosinfo load its

As some of you already know, I've been working on a simple AV-specific control-point as part of gupnp-tools. While at it, I've been trying to keep the UPnP AV parts as separate and generic as possible so that they could be move to a separate library later on. One of the first things that everyone wanted to create a nice wrapper for is the ugly DIDL-Lite. Jorn tried his best to convince me and others to not create a GObject for representing each DIDL-Lite object but I didn't listen and ended-up writing a very resource hungry API. To see what i mean, please look at memory usage of gupnp-av-cp after populating it's treeview with the content hierarchy exported by coherence: I was quite sure that most of this 28M is taken by xmlDoc and I was right. Now that I have got rid of xmlDoc usage and replaced the gobjects with an API to deal with xmlNodes, here is how the memory usage looks like: For people who are curious on how this simple AV control-point would look like, here is