Re: smppbox

Thanks,

As I see, the external box approach was used. Proceeding with documentation. 
Will submit to Rene for final approval and creation of the doc subdirectory 
in the trunk.

BR,
Nikos
----- Original Message ----- 
From: "Alexander Malysh" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: "Alejandro Guerrieri" <[email protected]>; "Kannel Devel" 
<[email protected]>; <[email protected]>
Sent: Monday, June 14, 2010 11:46 PM
Subject: Re: smppbox


Hi together,

I just created new project in SVN and redmine. Please check it.
@Rene: I enabled Manager role to you for SMPPBox in redmine.

SVN:
https://svn.kannel.org/smppbox/trunk

Thanks,
Alexander Malysh

Am 08.06.2010 um 13:50 schrieb Nikos Balkanas:

> Thanks Alex,
>
> A final overlooked point in deciding whether it should be a separate box 
> or not, is maintainability. Right now you are the only person 
> administering bearerbox + smsbox, with obvious advantages. Expanding this 
> architecture will mean more work for a single person, you, so it would be 
> better in this light to offload it to someone else, as a separate box.
>
> So you do have a saying in the matter, after all.
>
> If it is implemented as a separate box, I could help with its 
> maintenance/administration.
>
> Let me know how you will proceed to start working on the documentation.
>
> BR,
> Nikos
> ----- Original Message ----- From: "Alexander Malysh" <[email protected]>
> To: "Nikos Balkanas" <[email protected]>
> Cc: "Alejandro Guerrieri" <[email protected]>; "Kannel Devel" 
> <[email protected]>; <[email protected]>
> Sent: Tuesday, June 08, 2010 10:48 AM
> Subject: Re: smppbox
>
>
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>