RE: additional modules

--On Wednesday, May 22, 2002 5:25 PM +0200 Oded Arbel <[email protected]> 
wrote:
>
>> Perhaps, I did not explain my thoughts so well, but I want
>> to start additional threads without patching the core code.
>> Just wondering who on this list provides additional products
>> around Kannel by patching the core?? I would for SNMP.
>
> I agree that a run time linking API for modules would be nice, and allow
> companies to distribure binary modules that were developed to support
> proprietry standards, among other things. and while this is not high
> priority in the to do list of any current Kannel developer, in the
> spirit of open source you are more then welcome to contribute the code
> to do that to the Kannel development effort :-)

Since, I am currently jobless I will see what I can do. I maybe will
do it in the spirit of open-source. Although, I would not be that
happy if others make big-time money with it. :-))

>
> AFAIK no one around supplies additional modules for Kannel that are not
> part of the Kannel distrebution. My company at least have several
> modules developed in house that are not part of the distrebution, and
> were developed by adding entries to the relevant source files.

I would like to avoid that. it would also be a benefit for all
companies involved, due not maintaining changes needed in the core
all the time.

>
>> Currently, the 'bearerbox' process spawns of 6 threads
>> and I (as part of a prototype) have to spawn an extra thread
>> for the SNMP agent in order to provide near-realtime statistics
>> of the complete WAP gateway.
>>
>> As for an API, I see only a need for start_thread and stop_thread so
>> far, but m aybe there would be more, like a data parameter.
>> Followed by that maybe additional configuration APIs, since each
>> module has potentially an additional private configuration part.
>>
>> I hope this explain it better.
>
> You are not speaking of SMSC modules (which I though you were talking
> about at first). as such, deaper patching of the code is required. What
> you need is a much more general API for run-time linking of shared
> objects, and is much harder to do then previously discussed options,
> such as an API for SMSC modules or an API for sms-service modules. maybe
> designing one is in order.

I will come up with something to shoot at. Maybe it will directly
not be perfect. However, I would like to know whether some
companies who are maintaining there own additional modules
tell me which hooks they would need.

For instance,

init_module
start_thread_module
stop_thread_module
log_module

>
>> Now more a point of implementation. I believe there are 2 things
>> important. The end-goal and a smooth transition in which all the
>> time the gateway can work. The transition can be done quick and
>> rigurous or step by step (just slower).
>>
>> I think the step by step approach is preferred, since every
>> one can check
>> and keep doing there own parts of development as well test it all.
>> Therefore, I also believe we should agree on some way forward in which
>> we first make all calls to various module are threads equal (The
>> smsc.c call are already that way). That also is more
>> internals and thus
>> less influencial for external module development.
>
> If you are planning on a redesign of the entire infrastructure of
> Kannel, please supply detailed design ideas if you want meaningful
> responses.

I understand this. but I was mainly touching the field
whether there would be any interest and how people add there
propriatary modules. Also since I see that for instance an SNMP
module would benefit Kannel, but needs currently changes in the
code. (OK, I will admit that maybe SNMP always needs that in
order to provide certain management info or function. But don't tell
anyone this yet :-)



Harrie

Internet Management Consulting
tel: +39-3474932300
mailto:[email protected]                http ://www.mod-snmp.com/