> -----Original Message----- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 7:21 PM > To: Oded Arbel; dev-kannel > Subject: RE: additional modules > > > HI Oded, > > --On Sunday, May 19, 2002 8:45 AM +0200 Oded Arbel > <[EMAIL PROTECTED]> wrote: > > > It's easy to add a new "SMSC" module using the current API. > all you need > > to do is write a new C file for your module, supply the necessary > > callbacks and register it in smscconn_p.h and smscconn.c. > > > > see the recently submitted smsc_cgw.c for a good example. > > I see what you mean. I was actually thinking of a more modular > approach for the main functionality via which no other part/C-code > needs to be changed in order to add this extra module. Correct me > if I am wrong but with the smsc.c file one still needs to adapt > this file in order to have an extra module.
No - that is not correct, changing the smsc.c file is the _old_ API, which is not used for newer modules. new modules should be written for the SMSCConn API and need fewer changes in the Kannel source codes. > 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 :-) 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. > 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. > 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. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Businesses may come and go, but religion will last forever, for in no other endeavor does the consumer blame himself for product failure.
