Returning on yesterday’s blog entry, today I’ll see to update you on the status of xine-lib’s XDG support.
Thanks to Mark Nevill, I didn’t have to reinvent the wheel by parsing the various XDG_ variables to check for the directories I have to search in; he already wrote a libxdg-basedir library that takes care of most of it, allowing me to take care of the implementation details.
Now, xine-lib-1.2 branch has an internal copy of libxdg-basedir (two source files, so it’s not a big deal, and I’ve added a switch to use the external copy of it if needed), and uses it to decide where to read and write some files.
For instance, the plugins cache is no more in ~/.xine/catalog.cache but it’s in $XDG_CACHE_HOME/xine-lib/plugins.cache which both makes more sense and can be decided by user to be moved out of its home (for instance I change the value to XDG_CACHE_HOME, but that’s a topic for another post). The CDDB cache is also moved on the cache home, while the fonts are now discovered in the XDG_DATA_DIRS defined paths. Darren also moved channels.conf load from ~/.xine to XDG_CONFIG_HOME, which means it’s loaded in ~/.config/xine-lib by default.
Please note that I’ve been using xine-lib all over rather than xine, so that users know what is generated/handled by the frontends and what is actually part of the library, if they care.
There are still a few changes pending, for instance Darren wants to support loading of a system-level channels.conf, so that it can be put in /etc/xdg and used for all users without having to put it in xine’s configuration for every user.
I’ve also decided to pay more attention to the security side of xine-lib, for instance, after talking with Taviso today, I’ve added a xine_xcalloc function to wrap around calloc, which should avoid possible overflows (there was one in input_dvb); I’ve changed some of the code, but of course it’s not totally cleaned up. xine-lib really should be audited piece by piece for improvement, every time I touch something I end up cleaning it up by adding more const keywords (trying to let the compiler optimise a bit more) and adding/removing/cleaning up code .
One thing that certainly would help would be to put a better wall between contributed code (where we should always do the work on upstream’s side and then merge it back into xine-lib, to avoid getting them out of sync, unless fixing some xine corner case or similar—although there it could certainly help to put a proper wrapping around the two), and the xine proper code that should fixed/cleaned/improved as we go.
Really, while xine actually do its job most of the times, it still suffers from a lot of possible problems just because the code is too old and stratified. I think I should simply undergo an audit file per file trying to fix stuff while I also update the documentation to be doxygen-compatible, but that’s going to take so much time that I’m not sure how realistic is to work on it; beside I don’t have hardware such as a DVB tuner that would allow me to complete the audit (I can’t try that code and I can’t ensure its working state).
On the other hand, tonight I fired up Klothos again; it has been some time since I’ve done any Gentoo/*BSD work, but I’ve lately asked Roy to put me back in bsd@gentoo.org alias, to see if there is work that needs to be done that I can do. Yes, I suppose I’m considering coming back, but if I will do that, it will be on a lower profile; maybe I’ll help Mike, Frysinger, SpanKY and vapier with the ARM architecture, maybe I’ll just decide to take care of BSD alone.
The problem with Klothos is the PSU; the whole box is quite silent, as the UltraSPARC CPU is cooled by a slow and silent fan, but the PSU is annoyingly noisy, and I can’t just put a be quiet PSU like I put on Enterprise because of the Ultra5 casing (it’s a desktop machine, the case is high as the ATX power supply, which means the big fan used by most silent units would be obstructed by it); I could try a passive PSU, as the box shouldn’t be sucking too much power anyway, but I’m not sure about it and I don’t have money to waste (at the moment I’m unemployed).
If anybody has a suggestion about which PSU I could use for such a box, it’s really appreciated. It’s funny that I paid ?35 for a working box, and then paid way more to bring it to a standard worth to be a dev machine… well, I got the SATA controller already in my possession, as well as the SATA hard disk; the DVD reader was also an old one I used, but I had to buy a new ethernet card to avoid using the obnoxious hme0 driver..
