Well, there's no "one size fits all" approach. As Rene put it, both approaches has pros/cons and every box has its market.
Regards, -- Alejandro Guerrieri [email protected] On 07/06/2010, at 19:06, Nikos Balkanas wrote: > Hi, > > Scalability is a compelling reason. Except that current smppbox has a minimal > footprint (1 source file?) and can easily fit in a bb. For scalability think > of 5 bb with smppbox activated, and another 3 without (could be a > configuration directive). First 5 could handle all ESME connections, while > last 3 could handle all MTs. > > Smppbox overhead is now minimal. We should consider splitting it when it > becomes a limiting factor, or too complex. Being in function just a > transparent SMPP proxy, with possible DLR rewriting, I don't see any reason > to ever become very heavy. > > BR, > Nikos > ----- Original Message ----- From: "Alejandro Guerrieri" > <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: "Rene Kluwen" <[email protected]>; <[email protected]> > Sent: Monday, June 07, 2010 7:45 PM > Subject: Re: smppbox > > > Well, there's (always) a tradeoff between simplicity and scalability, isn't > it? > > Regards, > -- > Alejandro Guerrieri > [email protected] > > > > On 07/06/2010, at 18:37, Nikos Balkanas wrote: > >> Hi, >> >> Didn't intend to be pendatic. Whether smppbox is accepted in the trunk or >> main tree, it is still being accepted, and documentation must follow. >> However, if smppbox is rejected, no documentation is needed. If it is >> revised, documentation will again have to wait for final implementation. >> >> I am familiar with smppbox functionality from Stipe's release. However, bb >> is the hub for all external non-HTTP connections. I like current smppbox >> simplicity and efficiency (it has faster I/O than an external box). >> Currently it is a bb part and considerable redevelopment will be needed to >> make it a standalone box. Unless a compelling reason exists to externalize >> it, I wouldn't want to. But this is just my 2 cents worth. >> >> Cheers, >> Nikos >> >> ----- Original Message ----- From: "Rene Kluwen" <[email protected]> >> To: "'Nikos Balkanas'" <[email protected]>; "'Alexander Malysh'" >> <[email protected]> >> Cc: <[email protected]> >> Sent: Monday, June 07, 2010 5:34 PM >> Subject: RE: smppbox >> >> >>> 1. Thanks for the lecture. But documentation needs to be written anyway, >>> either if the code will be part of the gateway trunk or separately. I am too >>> busy myself to come up with some proper document any time soon. >>> >>> 2. I think you understood it wrong. Smppbox is similar to sqlbox with >>> regards that it connects to bearerbox, just like smsbox. The patch is made >>> for Kannel, but smppbox could easily be converted to some kind of >>> smppbox-standalone, just like sqlbox is. You need to start it separately >>> from bearerbox. >>> >>> So in short: Also a separate box, not required by everyone (as well as >>> wapbox also, which happens to be part of Kannel). >>> >>> == Rene >>> >>> >>> -----Original Message----- >>> From: Nikos Balkanas [mailto:[email protected]] >>> Sent: maandag 7 juni 2010 16:26 >>> To: Rene Kluwen; 'Alexander Malysh' >>> Cc: [email protected] >>> Subject: Re: smppbox >>> >>> Hi Rene, >>> >>> You may not be aware of it, but there is a 2-step acceptance. Or better >>> phrased accept & commit. Once the patch code is accepted, the patch doc is >>> submitted. Then the whole package is committed to the svn. No sense after >>> all to create a doc if the code is never accepted, right? >>> >>> That's what i meant, and this is how it is traditionally handled. >>> >>> SQLbox is an independent separate box, and one that is not necessary to >>> everyone. SMPPbox is part of bearerbox. It can be activated or not based on >>> configuration. But this is a decision for Alex. >>> >>> BR, >>> Nikos >>> ----- Original Message ----- From: "Rene Kluwen" <[email protected]> >>> To: "'Nikos Balkanas'" <[email protected]>; "'Alexander Malysh'" >>> <[email protected]> >>> Cc: <[email protected]> >>> Sent: Monday, June 07, 2010 4:46 PM >>> Subject: RE: smppbox >>> >>> >>>> You contradict yourself now. First, you said documentation should be ready >>>> first to accept it. >>>> Now you say that you will write documentation when it is accepted. >>>> >>>> Either way, I was wrong in my original post. I thought that sqlbox was >>>> part >>>> of de gateway svn trunk already. But it is not. >>>> I don't know why not, other from historical reasons but I think (imo) >>>> smppbox should be treated the same way as sqlbox. >>>> >>>> Personally I think they both belong to 'gateway' instead of separate >>>> projects, because it is a lot easier for the users. >>>> But okay... if someone thinks they have a valid reason to have them split >>>> up >>>> (like the way it is now), it is fine for me as well. >>>> >>>> == Rene >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Nikos Balkanas [mailto:[email protected]] >>>> Sent: maandag 7 juni 2010 15:39 >>>> To: Rene Kluwen; 'Alexander Malysh' >>>> Cc: [email protected] >>>> Subject: Re: smppbox >>>> >>>> OK, then. When it is accepted in the main kannel tree. >>>> >>>> BR, >>>> Nikos >>>> ----- Original Message ----- From: "Rene Kluwen" <[email protected]> >>>> To: "'Nikos Balkanas'" <[email protected]>; "'Alexander Malysh'" >>>> <[email protected]> >>>> Cc: <[email protected]> >>>> Sent: Monday, June 07, 2010 4:21 PM >>>> Subject: RE: smppbox >>>> >>>> >>>>> I see an excellent opportunity for you, Nikos, to prove your skills, >>>>> writing >>>>> documentation :) >>>>> >>>>> -----Original Message----- >>>>> From: Nikos Balkanas [mailto:[email protected]] >>>>> Sent: maandag 7 juni 2010 14:12 >>>>> To: Rene Kluwen; Alexander Malysh >>>>> Cc: [email protected] >>>>> Subject: Re: smppbox >>>>> >>>>> Dear Rene, >>>>> >>>>> Thanks a lot for this contribution. Upon succesful acceptance by kannel >>>>> in >>>>> the main svn, bear in mind that an additional component will be needed: a >>>>> patch to kannel's User's guide. This is a requirement to every patch >>>>> submitted to kannel. Can you take care of it? >>>>> >>>>> @Alex: This is a long awaited feature to bearerbox. It is also the second >>>>> large contribution by Chimit. According to Rene it has been used in >>>>> production for over a year without problems. I would like to see it in >>>>> mainstream kannel. Is it feasible? >>>>> >>>>> My vote is +++1 >>>>> >>>>> BR, >>>>> Nikos >>>>> ----- Original Message ----- From: "Rene Kluwen" <[email protected]> >>>>> To: <[email protected]> >>>>> Sent: Friday, May 07, 2010 11:56 PM >>>>> Subject: smppbox >>>>> >>>>> >>>>>> Lectori Salutem, >>>>>> >>>>>> This email is about Chimit's smppbox. >>>>>> >>>>>> The rights to the smppbox code have been obtained by a third party, but >>>>>> fortunately there is some good news for the open source community. >>>>>> >>>>>> An early version of smppbox (smpp v.3.0) will now be donated back to the >>>>>> community. This version is by no means perfect and developers and >>>>>> investors >>>>>> are invited to contribute. All in the spirit of being an open-source >>>>>> community. >>>>>> >>>>>> Chimit already developed the successful sqlbox, which is now part of the >>>>>> main stream Kannel distribution, so if we all cooperate, this smppbox >>>>>> can >>>>>> go >>>>>> the same way. >>>>>> >>>>>> To get you started, here is a preliminary download: >>>>>> http://www.chimit.nl/kannel/smppbox.tar. >>>>>> >>>>>> Unfortunately, due to the expected response, we cannot give you support >>>>>> on >>>>>> this software, other than via the usual Kannel users mailing groups. >>>>>> There >>>>>> is nobody with experience on this particular matter of software, so >>>>>> please >>>>>> bear with me. I have little time to spend on free software. But >>>>>> releasing >>>>>> smppbox is a priority now, even when I cannot give sufficient support to >>>>>> all >>>>>> of you. >>>>>> >>>>>> If you want a carrier-grade, commerialy widely deployed smppbox or EMI >>>>>> server functionality, we direct you to the alternatives. For instance >>>>>> the >>>>>> smppbox that Stipe Tolj provides ([email protected]). >>>>>> >>>>>> Cheers to all, >>>>>> >>>>>> Rene Kluwen >>>>>> Chimit >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >
