Re: MMS Gateway, OMA OTA for Kannel, etc

It is true as David points out, that there are a lot of dependencies to 
Mbuni, and it is significantly different in outlook and design that we 
thought it best to start a new (related) project. A lot of the 
dependencies are inevitable (particularly with regard to content 
adaptation). That said, we have tried to keep away from linking with 
libraries, rather we use pipes to communicate with external progs.

  Mbuni really uses only two parts of Kannel: GWLIB and the WAP library. 
GWLIB currently has to be patched, because of the way the cfg module 
works (directives have to be compiled in). We also patch the makefile 
so that WAP libs (and headers) are installed/exposed. One interim 
option might be to fold the patch into Kannel.

On Feb 08, 2005, at 05:49, Davy Chan wrote:

> **>Date: Mon, 07 Feb 2005 21:19:04 +0100
> **>From: Stipe Tolj <[email protected]>
> **>To: Paul Bagyenda <[email protected]>
> **>In-Reply-To: <[email protected]>
> **>Subject: Re: MMS Gateway, OMA OTA for Kannel, etc
> **>Cc: [email protected]
> **>
> **>Paul Bagyenda wrote:
> **>
> **>>Hello All,
> **>>
> **>>  As well as putting the Mbuni MMS Gateway out, I have updated the 
> patches,
> **>> previously posted here, to enable Kannel send OTA settings using 
> OMA
> **>>formats. Please see
> **>> mbuni.org for details.
> **>
> **>*very interesting*.
> **>
> **>Just tried to give it a configure try on cygwin, but configure 
> complains
> **>about non-presence of dlopen.
> **>
> **>As you write in the docs section of the web-site it contains varios 
> MMx
> **>interfaces, like MM1 for the handset-to-MMSC, MM7 for VASP and MM4 
> for
> **>MMSC-to-MMSC. I scaned the code on a quick shoot for MM7 SOAP/XML 
> code, but
> **>didn't find anything?
>
> Their userguide has the answer:
>   "The initial release fully supports the MM1 and MM3 interfaces, and
>    provides rudimentary support for the MM4 interface.
>      :
>    Currently there is no support for VAS via MM7 protocols (SOAP or
>    EIAF), but this is planned and should be available soon."
>
> **>I don't know how you company is thinking about this, but I'd (and 
> obviously
> **>the Kannel Group itself) would like to get this components/project 
> boarded
> **>to Kannel itself. Is this an option, as we may provide 
> infrastructure and
> **>keep it as add-on "module" to Kannel's generic code base. In order 
> to get
> **>to many fragmented outsourced projects. This includes also the 
> recently
> **>sqlbox patches that should go into an own cvs module IMO.
> **>
> **>Any comments on these options?
>
> One problem I see might be that Mbuni does use the gwlib internally
> and Kannel as an external interface. But, the design philosophy is
> different from Kannel.  Kannel has been hesitant about depending
> other people's libraries unless absolutely necessary (libxml2 and 
> openssl
> are the only one's that immediately come to mind). As a result, 
> products
> based on Kannel are rather clean when it comes to licensing issues.
>
> Mbuni, on the other hand, uses plenty of external libraries and 
> applications.
> Some libraries are GPL'ed (libsndfile), some are LGPL'ed (most of SoX
> except the FFT.h, which is GPL'ed). I haven't had a chance to start
> looking into the code, but I'm hoping that they are using Lame and
> SoX through pipes instead of linking directly with the libraries
> (like mpglib). I understand the reasoning (why re-build the wheel?),
> but it does increase the level of dependencies.
>
> Actually, I have no problems with bringing them into Kannel if they
> want.  I just wanted to remind everyone that Kannel has a philosophy
> and we might want to remember it when thinking about including other
> people's work. I still remember the long and interesting 
> "conversations"
> about using a DSO-like framework for runtime plugin extensions to 
> Kannel.
> I can't remember if we might have lost a few good developers by
> beating them with the "dependency" issue. If nothing else, I would
> not want them to feel pissed off because we are planning on including
> so much dependencies without any formal debate.
>
> **>I'll give it a try on a Linux box close-by to see how far I get it
> **>"working".
> **>
> **>Stipe
> **>
> **>mailto:stolj_{at}_wapme.de
>
> And I, too, look forward to playing around with Mbuni.  Thanks Paul
> and ?Dave? for releasing it to the open source world!
>
> See ya...
>
> d.c.
>