Artem Pylypchuk schrieb:
Hello users Kannel mailing list!
I would like to inform you, that I've written some code for Kannel that can be
used for MSISDN provisioning over LDAP queries, with a flexible
failover/fallback mechanism (as required by our carrier partner). Please
consider adding it to your addons page.
The page with the addon is http://juice.org.ua (merged with my personal page),
the patch is at http://juice.org.ua/patch
Please note, that it's still just a sketch (i.e. [pre-]alpha), so it's not
integrated into configure script, and also, the question remains what to do
with the existing RADIUS accounting module (disable by config?). Everything
else works just fine (lookups, failover, failover fallback dummy checking &
configuration reading).
Hi Artem,
thanks a lot for sharing your work with us. We appreciate your
contribution highly. And I'd like to advocate and support you in getting
the code into our main CVS HEAD branch so we see it available in
upcoming releases.
First of all, please switch to the 'devel' mailing list instead for
this, since it's more related to development itself then usage
questions. That's why I have cross-posted to devel@ too in this response.
I see 4 points here we need to do to get the code into the mainline CVS
branch:
- apply our doc/CodingStyle guide lines to your source code files. To be
honest, they are way to "sloppy" and don't match our "style" ;)
- apply your changes to CVS HEAD instead of 1.4.1 stable and create a
'diff -u' patch, so we can post a clean patch to the mailing list for
letting other developers review it and vote on it's commitment.
- I guess OpenLDAP is the point of choice for the LDAP directory
backend? I can do the configure[.in] et al preparation for this, so we
have a clean build process w/o LDAP support.
- Concerning RADIUS acct vs. LDAP I would suggest the following way:
make the backend storage type configurable via config directive
'msisdn-storage' in the wapbox group. This config directive will be
interpreted and we simply use a neutral function pointer that is pointed
to the implementation function call name, ergo we don't need runtime
checks, it's just one check while startup and while runtime our module
calls the function it has been configured for. The function calls are
defined as public functions in it's modules, as is.
Looking forward to your updates patch to devel mailing list ;)
Thanks for your attention.
You're welcome. Good work so far. I hope you understand that we need to
fit our guide lines before applying changes to the CVS branch.
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
-------------------------------------------------------------------
