I wasn’t happy enough with the new format of plugins’ structures, using direct literals rather than having to define functions to return them. As I said before, it makes more sense to set the identifier, the description and the textdomain directly on the plugin_info_t, so that the plugin does not need to be initialised at all to have its name and the description.
So I started doing this now, and the result up to now seems quite interesting: there are a few extra dereferences in a couple of points, but the functions that load the description of the plugins are quite smaller now, as they don’t have to open the plugin anymore).
What is the problem now? The problem is that there are a bit more than 150 plugins in xine that needs to be modified to comform to the new interface, it’s not a quick task, and it’s actually quite boring. And everytime I do something like that I start to wonder why am I doing that, considering that I’m not paid to do this, and I receive very little feedback about xine…
Once all the plugins are converted, I should be able to assess the improvement and make sure that I didn’t break anything in the plugin loader.
After that, I’ll have to put hands on the catalog generator so that I can save the description on the plugins cache, which should improve even more the loading of descriptions.
And finally, when this is done, I’ll have to take care of all the demuxer plugins again trying to move extensions and mimetype information again directly on the structure exported by the plugin.
That is a prerequisite for having mimetype demuxer detection, which in turn is a requirement for Shoutcast to always work properly, one of the nastiest bugs in Amarok.
Now, I don’t want to appear a pusher, but as I actually know how I’m feeling, I can tell you that if you really want to see xine-lib 1.2 released someday next year, an appreciation sign is certainly useful 😉 That can be a “thank you” mail or comment, something from my wishlist or at least the bug reports going directly on the tracker…