Hi All, first of all: A BIG THANKS to Rene and Chimit!
To the architecture... It just a decision of the developer how it should be implemented. I would say that smpp server belongs to bearerbox because it's nothing as a regular SMSC module. But have SMPP server separated to extra box is not wrong and have some advantages, e.g. scalability if you have all the routing and business logic in the bearerbox. I will commit this code to the external project (please give me some time :) ) the same as sqlbox. Due to the fact that we use SVN now we can easy make externals to external projects in the gateway repository. Thanks, Alexander Malysh P.S. We have to think about splitting SMPP code into library to share it between SMPP client and server. Am 08.06.2010 um 01:33 schrieb Nikos Balkanas: > Oh, but I believe that yes, it does. Not as "one size fits all", but rather > as provided functionality, which is indicated indirectly from its size. > > Wapbox has clearly a lot of functionality, complexity and code, implementing > the whole wap stack layer along with a separate, distinct fucntionality, and > had to be splitted off to handle complexity, and offer an abstraction layer > to the rest of bb. Smsbox, although less complex, still has a distinct > functionality for all the same. SQLbox should have been functionally part of > smsbox, in my oppinion. > > SMPPbox offers a very specific, limited function related to bb (SMPP layer). > I consider it more as a bb enhancement, rather than anything else. > > But let's wait for Alex's input. > > BR, > Nikos > ----- Original Message ----- From: "Alejandro Guerrieri" > <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: <[email protected]> > Sent: Monday, June 07, 2010 8:14 PM > Subject: Re: smppbox > > > 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > >
