smppbox

Nikos Balkanas nbalkanas at gmail.com
Tue Jun 8 01:33:03 CEST 2010


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" <aguerrieri at kannel.org>
To: "Nikos Balkanas" <nbalkanas at gmail.com>
Cc: <devel at kannel.org>
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
aguerrieri at kannel.org



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" 
> <aguerrieri at kannel.org>
> To: "Nikos Balkanas" <nbalkanas at gmail.com>
> Cc: "Rene Kluwen" <rene.kluwen at chimit.nl>; <devel at kannel.org>
> 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
> aguerrieri at kannel.org
>
>
>
> 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" <rene.kluwen at chimit.nl>
>> To: "'Nikos Balkanas'" <nbalkanas at gmail.com>; "'Alexander Malysh'" 
>> <amalysh at kannel.org>
>> Cc: <devel at kannel.org>
>> 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:nbalkanas at gmail.com]
>>> Sent: maandag 7 juni 2010 16:26
>>> To: Rene Kluwen; 'Alexander Malysh'
>>> Cc: devel at kannel.org
>>> 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" <rene.kluwen at chimit.nl>
>>> To: "'Nikos Balkanas'" <nbalkanas at gmail.com>; "'Alexander Malysh'"
>>> <amalysh at kannel.org>
>>> Cc: <devel at kannel.org>
>>> 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:nbalkanas at gmail.com]
>>>> Sent: maandag 7 juni 2010 15:39
>>>> To: Rene Kluwen; 'Alexander Malysh'
>>>> Cc: devel at kannel.org
>>>> Subject: Re: smppbox
>>>>
>>>> OK, then. When it is accepted in the main kannel tree.
>>>>
>>>> BR,
>>>> Nikos
>>>> ----- Original Message ----- From: "Rene Kluwen" 
>>>> <rene.kluwen at chimit.nl>
>>>> To: "'Nikos Balkanas'" <nbalkanas at gmail.com>; "'Alexander Malysh'"
>>>> <amalysh at kannel.org>
>>>> Cc: <devel at kannel.org>
>>>> 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:nbalkanas at gmail.com]
>>>>> Sent: maandag 7 juni 2010 14:12
>>>>> To: Rene Kluwen; Alexander Malysh
>>>>> Cc: devel at kannel.org
>>>>> 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" 
>>>>> <rene.kluwen at chimit.nl>
>>>>> To: <users at kannel.org>
>>>>> 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 (st at tolj.org).
>>>>>>
>>>>>> Cheers to all,
>>>>>>
>>>>>> Rene Kluwen
>>>>>> Chimit
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>





More information about the devel mailing list