On 14.11.2006, at 02:26, Juan Nin wrote:

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.

I don't see why .dso support for SMSC is of any help There are not really any benefit to dynamically exchange SMSC modules as kannel is the only user of this .dso


b) various upgrades in the WAP 1.2.x stack

granted

c) integration of HTTP proxy abilities to play WAP 2.0 HTTP proxy

A standard HTTP proxy does that. I dont see us reinventing the wheel when we have apache, Squid and others doing it perfectly ok

d) WTLS??? anyone?

Long overdue. no one seems to be hot on doing it though and so far everyone can live without


e) MMSC??? ... which some of us have already.

MMSC is not really the same as the goal of Kannel even though Kannel can be a helper there. Furthermore there are not many demands for MMSC's as most operators block access to their MMSC network so a non operator can not make use of it.


f) IMPS???

What's that?


g) SMSC capabilities, on top of SS7 stack???

SS7 / SMSC capabilities are a MAJOR step. We developed this ourselves and it took us several manyears to complete. Note that unless you are a operator, SS7 wont get you anywhere. So the typical kannel user will never have a possibility to use it.


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.

Sure. you can restart from scratch and do your own kannel with less performance and more bugs.

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.

I disagree on this one. Not everyone talks Java neither. And there's not less code. Thats for sure.


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...

TLV is something which is SPECIFIC to one SMSC driver (SMPP) and is not supported in any other.
Furthermore TLV's are used usually for operator specific quirks. Not something standard. And for that its perfectly ok to maintain your private patch to add this private feature as you will most probably the only one needing it.

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 didnt follow that patch but setting the sender in a wap push makes sense and as far as I know it worked in the past simply by &from=...
I'm sure if you provided a patch it wont get rejected because no one wants to have that feature. Most of the time no one had time to add it or voting never happened.

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?


lots? where is this lot?


Andreas Fink
Fink Consulting GmbH
---------------------------------------------------------------
Tel: +41-61-6666332 Fax: +41-61-6666331  Mobile: +41-79-2457333
Address: Clarastrasse 3, 4058 Basel, Switzerland
---------------------------------------------------------------
ICQ: 8239353
MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink
Yahoo: finkconsulting SMS: +41792457333



Reply via email to