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 :)
--
.O.
..O Enver ALTIN | http://enveraltin.com/
OOO Software developer @ Parkyeri | http://www.parkyeri.com/
signature.asc
Description: This is a digitally signed message part
