Rene Kluwen wrote:
-1 from me.
Reason 1:
Does this mean add-ons need to temporarily use an interim API and switch to
another API when it becomes available?
now, this is a solution for add-ons to use a "add-hook" based approach. So this
_can_ be considered an API format for the adding of the config semantic checks.
If the add-on box uses the libgwlib.a:cfg.o API for loading/parsing and using a
Kannel styled config file, then it should "register" the new groups via a own
.def file and own 2 hook for the semantic checkers.
Reason 2:
mBuni, sqlbox require patches to the Kannel sources either way.
It doesn't matter if such patches also patch cfg.def or not.
now, this is what I'd like to reduce... better: eliminate.
For Mbuni, we almost reduced everything down to gwlib/mime.[ch] patchin. Paul
and I look to sync things here. So Mbuni can use the libs instead of mangling
the code and re-compile for patched libs.
Conderning configure.in and Makefile.in. A add-on box/module should have it's
own set of these. I can prepare a simple foobar example add-on CVS module for
that to show how simple an own add-on moule can be "plugged" to the Kannel core.
I use this for smppbox and others.
The aim is: Users configure and build a core Kannel gateway. Do a "make
install", and afterwards no patching is required to use the core Kannel libs and
it's functionality for add-on modules/boxes.
I didn't peek into sqlbox lately. But if it requires patching Kannel core, then
it's cleaner to abstract the "needed" functions to Kannel core, add them
permanently and hence eliminiate the patching.
Did I convince you towards a -0 at least? ;)
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
