I'm writing a component that does quite a lot of stuff (specifically, I'm writing my own version of foo_softplaylists, which queries last.fm and matches the results against the local library as best it can). I think part of that stuff will be useful in and of itself (the part that finds the best version of a track), and may also be useful to other components (such as an XSPF playlist loader which would need to fuzzily match tracks)
My question is: how do I go about doing this? I know components like ColumnsUI exist that other components can 'plug in' to, which must be exposing some API, but I've no idea how the foobar API wants me to do that.
I also have no idea what the policy on component dependencies is,
and if there's any facility in foobar to ensure that users have dependent components.
I would strongly recommend against doing this unless you've got a real need to do this, as users will end up mismatching your components. I did this with early releases of foo_wave_seekbar, which has a companion foo_wave_cache component that handled the scanning and storage of waveforms, while the display component was just the UI bits and bobs. My competent testers constantly screwed this up to the grade that I realized that it would be completely unfeasible to release such an elegant scheme to the world.
If this is productive process, why are you doing it if such component exists?
1. I have no idea what it takes, but make XSPF native to foobar, in a manner that I can double click XSPF playlist file and foobar will understand it2. foo_softplaylist XSPF reader doesn't understand url links, maybe you can enhance it trivially like that, and overcome need of foo_xspf component
You define a service interface with a corresponding GUID. You need to provide the header files (and some static libraries for the GUIDs) to other components. You can take the foobar2000 SDK itself or the Columns UI SDK as examples. You should also provide documentation if you want to provide an official API to your component. Interface versioning works pretty much the same way as Microsoft COM. If you change the interface you have to change the GUID as service binding at runtime uses only the GUID. Otherwise bad things are bound to happen.The good part: you are free to plug into any component that exposes an official API. Using undocumented, reverse-engineered interfaces if frowned upon (at the least).The bad part: there is no such facility. As Zao pointed out it is all up to the user to ensure a correct setup. As developer you can only build safety checks against missing dependencies.
You would also have to be careful of not relying on any particular initialization order of your components. There's intentional randomization of such things to avoid accidental reliance on such.