RE: version 1.1.6 processing limits
I'm not sure how "native" malloc works, but the checking malloc (which we use always) has an upper limit on the number of allocations allowed. if you want to use more memory you will have to recompile. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. "All books can be indecent books, but recent books are bolder; For filth, I'm glad to say, is in the mind of the beholder. When correctly viewed, everything is lewd! I could tell you things about Peter Pan (and the Wizard of Oz, there's a dirty old man) ..." --Tom Lehrer > -Original Message- > From: Cold Feet [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 4:16 AM > To: [EMAIL PROTECTED] > Subject: RE: version 1.1.6 processing limits > > > hi again, > > does it help and give better result if i upgrade the memory > to say 1GB from its present 256MB configuration? since kannel > is thread oriented in implementation, it uses memory to > handle transactions, if i have more memory in place, then it > could handle more threads at a given time... correct me if i > am wrong... anyhow, this is just my thoughts... > > > > - Original Message - > From: "Oded Arbel" <[EMAIL PROTECTED]> > Date: Wed, 29 May 2002 11:03:09 +0300 > To: "Cold Feet" <[EMAIL PROTECTED]> > Subject: RE: version 1.1.6 processing limits > > > > This question should be asked on the users list. > > In recent test we've run, we pushed about 25 messages a > second, which > > was limited mostly by our middle tier setup then by > kannel. I estimate > > that Kannel alone can go much higher then that. > > > > -- > > Oded Arbel > > m-Wise Inc. > > [EMAIL PROTECTED] > > (972)-67-340014 > > (972)-9-9581711 (ext: 116) > > > > ::.. > > X windows: > > A new level of software disintegration. > > > > > > > -Original Message- > > > From: Cold Feet [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, May 29, 2002 4:57 AM > > > To: [EMAIL PROTECTED] > > > Subject: 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 SD! > > > RA! > > > M. 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 > > > > > > > > > > > > -- > Surfy! http://www.surfy.com Great web search, free web > email, and $9.95 unlimited Internet access > > > > > > > > > > > Powered by Outblaze > >
Re: (no subject)
you are right Jose, i downloaded binutils and libinconv and work fine, In google newsgroups many people has the same problem, i think is good idea for Kannel put this information in the source package. I compile Kannel for work in Solaris 2.6 and works very fine. I use in Kannel in a CDMA PCS network, for WAP/Web SMS messages. Thanks for you Help. >From: Jose Borges Ferreira <[EMAIL PROTECTED]> >To: Gustavo Sepulveda <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: (no subject) >Date: 19 May 2002 23:54:17 +0100 > >I had the same problem. After some research i concluded that gcc don't >like the Sun Assembler so i intalled binutils package from SunFreeware >and every thing ( not only kannel ) started to compile. > >I have some patches to Solaris build and worked fine on Solaris 2.8. Can >you test them on 2.6 > >OT: If you have any troubles compiling perl modules i also recomend a >upgrade to perl. > > >On Fri, 2002-05-17 at 05:07, Gustavo Sepulveda wrote: > > > > Hello guys: > > I am trying to compile gateway 1.1.6 in Solaris 2.6 plattdform, i >instaled > > libxml2, and other requiremnts to compile kannel, but when execute make, >the > > followed messaged is sent by make: > > > > > > bash-2.05# make check > > gcc -D_REENTRANT=1 -I. -DSunOS=1 -I/usr/local/libxml/include/libxml2 > > -I/usr/local/ssl/include -o gw/bb_boxc.o -c gw/bb_boxc.c _ Hable con sus amigos en línea, pruebe MSN Messenger: http://messenger.msn.es
RE: version 1.1.6 processing limits
hi again, does it help and give better result if i upgrade the memory to say 1GB from its present 256MB configuration? since kannel is thread oriented in implementation, it uses memory to handle transactions, if i have more memory in place, then it could handle more threads at a given time... correct me if i am wrong... anyhow, this is just my thoughts... - Original Message - From: "Oded Arbel" <[EMAIL PROTECTED]> Date: Wed, 29 May 2002 11:03:09 +0300 To: "Cold Feet" <[EMAIL PROTECTED]> Subject: RE: version 1.1.6 processing limits > This question should be asked on the users list. > In recent test we've run, we pushed about 25 messages a second, which > was limited mostly by our middle tier setup then by kannel. I estimate > that Kannel alone can go much higher then that. > > -- > Oded Arbel > m-Wise Inc. > [EMAIL PROTECTED] > (972)-67-340014 > (972)-9-9581711 (ext: 116) > > ::.. > X windows: > A new level of software disintegration. > > > > -Original Message- > > From: Cold Feet [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 29, 2002 4:57 AM > > To: [EMAIL PROTECTED] > > Subject: 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 SD! > > RA! > > M. 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 > > > > > > -- Surfy! http://www.surfy.com Great web search, free web email, and $9.95 unlimited Internet access Powered by Outblaze
Re: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
On Wed, 2002-05-29 at 08:39, Harrie Hazewinkel wrote: > > > --On Wednesday, May 29, 2002 3:45 AM +0100 Bruno Rodrigues > <[EMAIL PROTECTED]> wrote: > > > 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. > > I agree. CVS is for development and users do not like to apply many > patches themselves in order to get it into a certain state. But kannel have some special kind of users. Besides the ones that wants to test kannel against a modem or mobile, the majority are almost "power users" that don't get scared with terminology of stable and unstable. It's like beeing afraid of debian unstable :P > > 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 ;) > > You must be a lucky chap then. :-) I just have the facility to being able to have a production system to do debugging, and some knowledge to fix quickly if something goes wrong (and there's always the local bearerbox.old and smsbox.old ;) )
RE: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
On Wed, 29 May 2002, Harrie Hazewinkel wrote: > > If we start doing > > architectural changes on the CVS, while everyone is using it to build > > their production, we will break things for people who don't/can't know Perhaps lay down tags more regularly; perhaps every 3-6 weeks - to facilitate those folks. Label them alpha's if need be. Dw
RE: CVS usage question??
Maybe line-feed format has been changed from unix-like to dos-like. This could happen if you use Windows based tools to edit, etc. Angel. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: miércoles 29 de mayo de 2002 16:54 Para: Harrie Hazewinkel; dev-kannel Asunto: RE: CVS usage question?? It's possible, if your editing tool reformats tabs and removes spare spaces and such. try to diff all the changes agains the current cvs, and then edit the diffs and remove everything that isn't requires for the patch. then you can checkout from the CVS again, apply the diffs you've edited and commit. Alternativly you can either switch to another code editor, or - commit all the files anyway and hope that your editor will not change any more files. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Was it Ritchie or Thompson who said about X: "Sometimes, when you fill a vacuum, it still sucks"? > -Original Message- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 2:29 PM > To: dev-kannel > Subject: CVS usage question?? > > > HI all, > > I wanted to commit changes in the gw directory. Although, only > 5 of the many files were changed. But in the 'cvs commit' it > showed almost all files to be chnaged. > > Has anyone seen it before?? > > > Harrie > > Internet Management Consulting > mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ > > >
RE: CVS usage question??
It's possible, if your editing tool reformats tabs and removes spare spaces and such. try to diff all the changes agains the current cvs, and then edit the diffs and remove everything that isn't requires for the patch. then you can checkout from the CVS again, apply the diffs you've edited and commit. Alternativly you can either switch to another code editor, or - commit all the files anyway and hope that your editor will not change any more files. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Was it Ritchie or Thompson who said about X: "Sometimes, when you fill a vacuum, it still sucks"? > -Original Message- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 2:29 PM > To: dev-kannel > Subject: CVS usage question?? > > > HI all, > > I wanted to commit changes in the gw directory. Although, only > 5 of the many files were changed. But in the 'cvs commit' it > showed almost all files to be chnaged. > > Has anyone seen it before?? > > > Harrie > > Internet Management Consulting > mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ > > >
RE: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
--On Wednesday, May 29, 2002 11:00 AM +0300 Oded Arbel <[EMAIL PROTECTED]> wrote: >> >> 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. >> >> > > I do not agree - we cannot even think of architecture changes while > everyone is building their production systems from CVS. I agree here. > while here we > also build our production from CVS by choice, for the same reasons you > stated, this is a "bad thing(tm)". it's our obligation to supply a > "stable" branch for people who rather have something that is known to > work, then the bleeding edge (which is most people). I would say (as mentioned in other emails) take the branch for a stable release version. Those should not change that much as the main branch were development is done. > If we start doing > architectural changes on the CVS, while everyone is using it to build > their production, we will break things for people who don't/can't know > how to handle it. I simply do not understnad why people in the first place use a, so-called, non stable CVS version in the production. It is well possible that it si not even tested well enough. > > So a branch is a must before doing any major surgery on the code. I agree. However, I believe that the main branch should be the main development line, unless it would be something very experimental. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE:first draft and patch for module oriented API
--On Wednesday, May 29, 2002 12:18 PM +1000 Ignat Vassilev <[EMAIL PROTECTED]> wrote: > Hi Harrie > > I tried to compile kannel with modules.patch but i recive error Hmm, I will try top built a patch again. I tested it here a few times and compilation was OK. Except for the test tools. I did not bother to mamke changes there. 1) Did you do a 'rm .depend ; gmake .depend'?? Otherwise, the new files (resulting in an object-file) do not end up in the libraries. 2) It also could be that the required patch lines (that includes the file bearerbox_modules.h) in the bearer_box.c did not went correctly. 3) It was a patch for the 'HEAD of CVS'. Hang on, I will see what really goes wrong. Since I did a change in CVS, the patch will change as well. New one will be provided soon. > > 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 > Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
CVS usage question??
HI all, I wanted to commit changes in the gw directory. Although, only 5 of the many files were changed. But in the 'cvs commit' it showed almost all files to be chnaged. Has anyone seen it before?? Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
If we are to continue to use CVS as a bug fixing and feature adding mechanism then we have to do this branching. Not doing so is going to mean that none of the 'live need to fix it now' problems get fixed (or submitted back) as nobody can properly diff against the bits they've fixed. Alex On Wed, 29 May 2002, Angel Fradejas wrote: > >If we start doing > >architectural changes on the CVS, while everyone is using it to build > >their production, we will break things for people who don't/can't know > >how to handle it. > > >So a branch is a must before doing any major surgery on the code. > > Totally agree. > > [ Even if I am a "CVS bad guy(tm)" ] > > > Angel Fradejas > Mediafusión España, S.A. > [EMAIL PROTECTED] > www.mediafusion.es > Tel. +34 91 252 32 00 > Fax +34 91 572 27 08 > > -- Alex Judd http://www.skywire.co.uk
MMS Proxy-Relay support
Title: MMS Proxy-Relay support I am establishing a test environment for WAP and also need to include MMS messages within the test environment. What are the plans & timeframes for adding support to the WAP Gateway to act as an MMS Proxy-Relay? Also will fakewap have added support for MMS? Thanks, T.K.
RE: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
> Maybe it is also needed to establish of how many of the group > should support or oppose to it before it is decided to what > will be added. Something like this is needed when you have a one branch development. when you branch the developers away from the stable release - why bother ? everyone who has CVS access can commit features as long as care is take not to break anything and proper notification is done (current devel-reports is more then enought - just remember to document your changes in ChangeLog). only conceptual/architectual changes need to be discussed in the open. > >> > - branch the tree now (yesterday would have been a good > time too ;-) > >> > and label it 1.2.0. > > Why do you already want a branch?? > Why not putting the releases into a branch?? > (Just asking) > Since this way you just can keep developing. > > As for a release I would suggest name it 1.2.0 > Make a branch of it and do new releases as 1.2.x > Continue development in the main branch for 1.3.y. Semantics. I don't mind what you call it, as long as we have a stable branch and a development branch. > > But for that, before thinking in branches and releases, we should > > think in the new architecture. > > I concur. The only thing is what kind of things do we put on the list. > You already mentioned some. After what we have to define how indeed. Why bother - you can't make architectual changes w/o branching the tree - you need to get a declared stable release before rewriting the entire code base, so people will have something to put on their production servers while the project's next generation is in limbo. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Keep me away from the wisdom which does not cry, the philosophy which does not laugh and the greatness which does not bow before children. -- Kahlil Gibran
Re: Patch submission and release policy (Was: [PATCH] problems withHTTPS and base support for per message billing)
--On Wednesday, May 29, 2002 3:45 AM +0100 Bruno Rodrigues <[EMAIL PROTECTED]> wrote: > 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. I agree. CVS is for development and users do not like to apply many patches themselves in order to get it into a certain state. >> > 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. Maybe it is also needed to establish of how many of the group should support or oppose to it before it is decided to what will be added. >> > >> > 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. Why do you already want a branch?? Why not putting the releases into a branch?? (Just asking) Since this way you just can keep developing. As for a release I would suggest name it 1.2.0 Make a branch of it and do new releases as 1.2.x Continue development in the main branch for 1.3.y. >> > - 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. If the current CVS version is way more stable, I think a new version is an needed. >> > >> > 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 ;) You must be a lucky chap then. :-) > > > 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. Depends, I would say. Maybe a release would require a branch and keep working on head. > > But for that, before thinking in branches and releases, we should > think in the new architecture. I concur. The only thing is what kind of things do we put on the list. You already mentioned some. After what we have to define how indeed. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
>If we start doing >architectural changes on the CVS, while everyone is using it to build >their production, we will break things for people who don't/can't know >how to handle it. >So a branch is a must before doing any major surgery on the code. Totally agree. [ Even if I am a "CVS bad guy(tm)" ] Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
> > 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. > > I do not agree - we cannot even think of architecture changes while everyone is building their production systems from CVS. while here we also build our production from CVS by choice, for the same reasons you stated, this is a "bad thing(tm)". it's our obligation to supply a "stable" branch for people who rather have something that is known to work, then the bleeding edge (which is most people). If we start doing architectural changes on the CVS, while everyone is using it to build their production, we will break things for people who don't/can't know how to handle it. So a branch is a must before doing any major surgery on the code. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Faith is believing what you know ain't so. -- Mark Twain
changes to the heartbeat code.
Hi, I have attached a patch to group the heartbeat code. If I hear/see no objections I will commit this. It changes: 1) adds a stop all heartbeat functionality by by means of the heartbeat_thread value of '-1' (ALL_HEARTBEATS) as the heartbeat_stop function. 2) move the heartbeat frequentie default value in the heartbeat.h (IMHO, where it belongs) 3) changes the wapbox.c and smsbox.c where the returned thread_nr is only used for providing a warning and the heartbeatthread_stop does a stop ALL_HEARTBEATS. regards, Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ heartbeat.patch Description: Binary data
