Enver ALTIN wrote:
On Mon, 2006-11-13 at 19:45 +0100, Stipe Tolj wrote:
Now, we're heading towards:
a) a more flexible automake, libtool et all build system and .dso support for
the SMSC modules.
b) various upgrades in the WAP 1.2.x stack
c) integration of HTTP proxy abilities to play WAP 2.0 HTTP proxy
d) WTLS??? anyone?
e) MMSC??? ... which some of us have already.
f) IMPS???
g) SMSC capabilities, on top of SS7 stack???
at least some "ways" we're heading... but as life is, nothing is for sure.
It's great to have some ways to head for in the long run, but I'd love
to see Kannel gain some abilities that would make life easier for most
people using it:
* Possibility to change some or all parts of configuration at
runtime (adding/removing log files, SMSC connections, services,
and so on).
* Possibility to change routing rules at runtime.
* Merge bearerbox and smsbox, and make the resulting animal behave
like any of these two when needed, or takeover the job of
another when it fails to do some task.
* Make Kannel as self-contained as possible: it would be great to
see it manage its own configuration and data (MO/MT/DLR queues,
WAP cache, etc.).
* More profiling and statistics support. What we have is just
the /status interface, we could have provided a lot of
throughput and performance related statistics per SMSC, per
service, per smsbox, and so on.
* Better support for dummy mode (fakesmsc). It looks like most
people are having some hard time learning how to get that beast
to actually work for some purpose.
* A GUI and/or web application to make these available to Joe's
grandmother.
* Switching to Subversion would also be good.
* Mantis is not so useful, I wonder if we could use Trac. I love
that timeline thing and also hosting the whole site in a wiki is
cool. That way we could make the userguide a collection of wiki
pages.
* I wonder if we could also overcome the issues I mentioned
recently about our release planning process.
Although I'm perfectly happy with it, I sometimes wonder why do we still
strive to do it with C. Kannel codebase itself aims to do some
object-oriented methods under the hood actually (SMSCConn, anyone? We
even have some sort of interfaces! yay!).
Now that Java is GPLv2, it might be an interesting challenge to port at
least some functionality of Kannel to Java (or some other modern
language, for the sake of discussion) and see how it goes.
I guess the biggest win would be a whole lot more readable and much
smaller codebase, we could get more people involved because not
everybody loves to code in C these days, and also it would be a bit
easier to maintain. With your suggestions I imagine the codebase getting
even larger, and soon we would be fighting against crime in it :)
Obviously we would be increasing hardware requirements and depend on a
larger stack, but hey, what the hell, let it be if that's really worth
it :)
I'd also like to know about certain needed functionalities that some
times there have been patches for them, and they have never been added
to Kannel
for example TLV support. I wrote about this some days ago, with not much
reply... just someone explaining a bit how to do it by coding into
Kannel (thnx, but it's complicated!). Shouldn't this be added in some
simple way to Kannel? I think many people need to use TLVs...
and what about the patch for setting the sender in Wap Push
I got my Kannel patched to do so, with a patch provided on the list, but
why don't add that patch or functionality to Kannel??
it's something it doesn't have sense not to have...
I'm not trying to be critic, Kannel's great and thanks to it all of us
are being able to work!!!
But why are lots of useful patches being left apart?
Regards,
Juan
