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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
