**>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: devel@kannel.org
**>
**>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.
