Re: Musings on public API

On Tue, May 19, 2009 at 08:44:01AM +0200, Holger Freyther wrote: 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, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)