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
