So, as I wrote earlier, I’ve used some of the code contributed by Matt Messier for xine-lib to implement the eject functon in libcdio for the OSX driver.
The question now would be: why does xine reinvent the wheel? Well, beside the fact that as we have seen, libcdio’s eject function was an hack for OSX at least, there is the need to make sure that we don’t have regressions; that is that all the operating systems supported by xine have a proper driver in libcdio that allows eject to work. I don’t think this is the case yet unfortunately.
My reasoning to make use of libcdio in that instance is that the code as it is is quite messy, and it’s not really something I’d like to see implemented for each and every operating system in xine: xine-lib shouldn’t be a generic abstraction layer for operating systems. This is why we use other libraries as backends for most things, like libdvdread and similar.
It wouldn’t even be much of an extra dependency, considering that libcdio is already needed to have proper VCD support; the worst thing that might happen, as far as I can tell, is that libcdio is proven an issue for some operating systems, requiring more porting work and various fixes, but I doubt that is a bad thing.
Having libcdio as a more prominent dependency might also help with other things like CDDA decoding and similar, maybe we should really investigate in that sense.
Anyway, when I’ll be back to Enterprise I’ll see to take a closer look at what should be changed in libcdio in my opinion: there is at least one thing I’d like to change: making the drivers’ build optional at file level. As it is, every source file uses preprocessor conditionals (#ifdef) to avoid building code when built on a different operating system than expected, and there is an extra function that reports at runtime the presence of a given driver; it doesn’t sound like that good an idea, considering that almost all of those are present or not at buildtime already (they are not plugins, they are builtin).
I doubt xine-lib-1.2 will be able to rely on a proper libcdio design and implementation, but maybe I’ll be able to work on that as a branch to merge later on, in an eventual 1.3 release. 1.3 where the API would also break (in 1.2 the only API break is related to audio plugins – output and postprocessing – for the audio conversion implementation).
So once again, for those interested in seeing xine-lib improve more, you’ll have to wait till mid-September when I’ll have my new hard disks (buying hardware in Italy in August is pretty much a bad idea, very bad idea); faster improvement might happen if I also get a whole new box, but that depends partly on whether I get some help or not, as I’m currently unemployed.
Anyway, as I end up thinking about a lot of design issues while I’m stuck here without Enterprise, I’ll probably discuss some of them on the blog from time to time. Both as a note to myself, and as a request for comments by who understand them 🙂
