Re: Future of Kannel

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