first draft and patch for module oriented API.
HI All, Attached is a document slightly explaining a module oriented API and a patch assoicated for it. I would people like to invite to make comments and in perticular those who made additional modules that need always patching the core. I understand it is not complete yet, but that is why I invite comments. Harrie Internet Management Consulting tel: +39-3474932300 mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ modules.patch Description: Binary data module_struct.txt Description: Binary data
lists/website downtime
Apologies for the downtime on the lists/website. The machine had crashed with a kernel oops. I just rebooted it and all seems well now. I'll keep an eye on it. Dave -- David Holland =*= Systems Manager =*= tel: +44 01223 478900 http://www.3glab.com/ =*= 3G Lab, UK =*= fax: +44 01223 478901
When Kannel 1.2 is likely to be released?
Hi Everybody I'm curious to know when Kannel 1.2 is likely to be release. Accordingly to the Roadmap, it should be released within April or early May of 2002. Is there a new roadmap? Thanks.
Re: first draft and patch for module oriented API
Hi Harrie I tried to compile kannel with modules.patch but i recive error gcc -D_REENTRANT=1 -I. -g -O2 -DBROKEN_PTHREADS=1 -I/usr/include/libxml2/libxml -I/usr/include/libxml2 -I/include -Wall -I/usr/include/openssl -I/usr/include/mysql -o gw/bearerbox gw/bearerbox.o libgw.a libwmlscript.a libwap.a libgwlib.a -lmysqlclient -lssl -ldl -lpam -lpthread -lresolv -lnsl -lm -L/usr/lib -lxml2 -lz -L/lib -lm -L/usr/lib -lcrypto -lssl -L/usr/lib/mysql -lmysqlclient libgwlib.a(modules.o): In function `is_allowed_by_module': /home/ozzy/kannel/gateway/gwlib/modules.c:54: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:56: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:57: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:67: undefined reference to `module_array_size' libgwlib.a(modules.o): In function `run_init': /home/ozzy/kannel/gateway/gwlib/modules.c:84: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:86: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:87: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:93: undefined reference to `module_array_size' libgwlib.a(modules.o): In function `run_start_thread': /home/ozzy/kannel/gateway/gwlib/modules.c:104: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:107: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:109: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:110: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:116: undefined reference to `module_array_size' libgwlib.a(modules.o): In function `run_stop_thread': /home/ozzy/kannel/gateway/gwlib/modules.c:126: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:129: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:131: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:132: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:134: undefined reference to `module_array_size' libgwlib.a(modules.o): In function `run_log': /home/ozzy/kannel/gateway/gwlib/modules.c:145: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:147: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:148: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:154: undefined reference to `module_array_size' libgwlib.a(modules.o): In function `run_exit': /home/ozzy/kannel/gateway/gwlib/modules.c:164: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:166: undefined reference to `module_array_size' /home/ozzy/kannel/gateway/gwlib/modules.c:167: undefined reference to `module_array' /home/ozzy/kannel/gateway/gwlib/modules.c:169: undefined reference to `module_array_size' collect2: ld returned 1 exit status make: *** [gw/bearerbox] Error 1 Regards Ignat
Re: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
On Mon, 2002-05-20 at 15:16, Stipe Tolj wrote: Oded Arbel wrote: Agreed. I was hoping that at least the billing issue (I remember it being talked about in the list a while back) would interest people. I do think, though, that fixes to problems not yet detected in the wild should go in anyway : that's why it's called a development tree, if the solution does not break anything - of course. IMHO, the current situation where the CVS build must never be broken because it is the production version and so patches require careful scrutiny before going in is not healthy. CVS _is_ the place to test fixes and new features - when you require that people will download and apply your patches one by one, the number of testers will shrink to the number of people interested in the specfic patch - which in a not-so-high visibility project like Kannel could easily get down to 1~2 people - or even less. case in point is the +CMTI patch by Alex Judd - it seems like a perfectly valid feature, but only 2 or 3 people on this list are at the same time interested and skilled to test iX-Mozilla-Status: 0009tences where some of them cannot find the time to do so, this perfectly good feature would simply be abandoned. I suggest we should roll out a release ASAP, using the following schedule : - branch the tree now (yesterday would have been a good time too ;-) and label it 1.2.0. - bug fixes may be submitted to either of the trees, and then ported to the other. - new features may be submitted only to the HEAD tree. - features and bug fixes will be submitted freely to the HEAD tree with minimum checks for style and obvious coding errors. - the HEAD tree will be considered unstable and fit only for development work. Using this method we would not further degrade the current situation (where people who have problems are told to upgrade their production servers to the CVS version - as it is more stable), while stabilizing the development effort for a full fledged stable release w/o hampering further feature development. Opinions please ? +1 for most of that. I was anyway concidering asking the developers about releasing 1.2.0. I'd like to hear from Bruno, Andreas and some others what they think about if current CVS HEAD is stable enough to make it a stable release 1.2.0? Well.. To be honest, using the CVS is an advantage because that way we get 100% testing and debug, code is done with less errors and bugs are fixed quicker ;) I'm always using cvs in production. Some bugs are only visible on production systems and I don't have time to do testings before upgrading. And if some message is lost, I can always blame the SMSC ;) There's some structural changes that we should do, and for that we really need a different branch. Modularity, new autoconf, real unicode support, etc. But for that, before thinking in branches and releases, we should think in the new architecture. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
version 1.1.6 processing limits
hi all, for the first month of being up on kannel 1.1.6 development release it has its ups and downs on its live run. on its first week several times it went down by itself... and so i recompiled it with additional flags and now have remained up and running and i can say i am to the point that i may say, the system and compilation issue is now stable for my server. however, i need a gauge on its processing limits. the system is handling sms only data and wap is disabled. and so far just a few number of sms is being received and replied to. i am hitting about 6,000 received sms in a day. all i know that this is just a small number to speak with. i would like to ask your input then, how much data can kannel process at any given time whereby it is really pushed to the limits. how many messages can it process in a given second or minute? to process a huge number of sms data, i need to have a good amount of RAM. i am using redhat linux 7.2 on an intel pentium III 866 mhz with 256MB of SDRAM. what do you think is a good server configuration to setup kannel. thanks -- Surfy! http://www.surfy.com Great web search, free web email, and $9.95 unlimited Internet access Powered by Outblaze
