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
