On Thu, 27.03.08 20:27, Colin Guthrie (gmane at colin.guthr.ie) wrote: > >> I'll then either adapt module-zeroconf-discover or copy it to a new > >> module in order to allow for autodiscovery or Airport devices. > > > > I'd recommend splitting this into two modules: One module that browses > > for RAOP devices and then loads the other module for each instance it > > finds. Much like the zeroconf-discover + module-tunnel work right now. > > :) I was actually going to use module-tunnel as my base for the actual > sink part so at least I'm in the right ball park. module-tunnel is certainly the worst module you could have picked. It's complicated, full of #ifdefs and doesn't even support all the newest fancy features of the core. > As I hinted above I'll either modify or copy the zeroconf-discover one. > I presume you'd prefer to make a separate module? Hmm, depends. It's up to you. A #ifdef based solution might be useful, i.e. conditional compilation of the RAOP and module-tunnel parts of zc-discover. That way you'd be able to share a single source and build two seperate modules of it. OTOH conditional compilation is a bit out of fashion these days. The alternative might be to split zc-disocver into three C files, and then compile two of them for one module and then two others for the other modules, if you understand what I mean. > Actually thinking about this, I can ask a small question that I've been > pondering today as it's vaguely relevant. > > As Pulse becomes more popular, how do you see managing the various third > party modules that start cropping up? I presume you don't want to > include them all in pulse svn etc. due to the increased overhead on your > good self (unless you dish out SVN accounts to various key people). Since I don't guarantee API stability there is practically no other option than having them integrated in PA upstream. This is what I ask people for: maintain your stuff in the PA build tree. Then I'll have a look over them from time to time and there's the chance that I'll be doing some porting to newer features for you. I am happy to hand out SVN access to people who submit useful code for modules to me. > So would you like to see more external projects, or keep everything > inhouse? It's not exactly a critical question, and an answer of "I've > not really thought about it" is perfectly acceptable :p In house, please. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
