Re: Ldap MSISDN provisioning patch for 1.4.1

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
-------------------------------------------------------------------