On Tue, May 19, 2009 at 08:44:01AM +0200, Holger Freyther wrote:
I just tried to come up with a patch to prefix the timer functions with bsc_ and started to think about public API. The thing is we only need to properly prefix symbols we intend to export. I don't think we will export timers.
well, it basically depens on how you want to see openbsc/libbsc.
If you treat it as a library, then of course exporting timers is a stupid idea. However, if OpenBSC is an application program / daemon that also supports plugins, then providing infrastructure such as timers to the plugins is a good idea.
I wasn't really sure about the way to go so far. I think in reality we might need both. The sole reason to have libbsc was that there is some code reuse between bsc_hack and bs11_config, and now even ipaccess_config.
I think all practical cases will not really see libbsc as a public library. I think the BSC functionality warrants its own daemon, possibly with multiple processes/threads, one for the signalling and one or more for the TRAU handling. The question is how to treat interfaces to programs like lcr.
Should we just offer a plugin API and let such users write a plugin that performs the IPC to the actual external program - or should we provide some kind of standardized IPC interface and a library that people can link into their application programs...
My main focus for OpenBSC has been to have a playground for BSC-like functionality that is as flexible as possible. So my intention is to have a toolkint of A-bis and other GSM prtoocol related bits (libbsc) plus a set of programs/plugins that can turn the code into something useful. a PBX is one of many examples, but a program that fuzzes telephones over the air would be another of those applications.
p.s.: I don't mind libtool at all.
Regards,