Howdy,
> + it is not possible to distribute for increased reliability & performance
I don't think this is true, quite the contrary in fact. That's what the
bearerbox does; distribution!
> + I had big problems porting to a 64-bit Solaris system. The code is not
> very portable in places
We didn't have any problems, and as far as I'm aware Derry Hamilton (who
did the original Solaris port) didn't have too many problems either. There
were a few issues centred on threads and signal handling, but a week or so
of work took care of those without too much drama.
> + the number of segmentation faults reported on this list leads me to
> believe that it has not been stressed
The CVS version certainly hasn't been too much, but the development releases
are fairly reliable.
> + the inability to deal with interleaved incoming and outgoing messages
> confimrs this
That's only one SMSC. The problems in that module have nothing to do with
Kannel archictecture, and everything to do with the nastiness of the GSM
AT command set implementation. So I disagree with that comment entirely.
> My 2c, is that Kannel should be redesigned into a number of layers :-
>
> [external interfaces, smtp, http, etc]
> [message formatters, dealing with TTML, OTA, MMS, ringtones, icons, etc]
> [transport manager, dealing with QoS, multiple smsc connections,
> cost/destination/performance based routing]
> [smsc connectors, much along the lines of the existing smsc modules, but
> running as discrete processes or Java threads]
These are good suggestions, though why "discrete processes"? And why Java?
> It should be 99% Java (although there may be reasons why the serial port
> handling is better done in C).
Ummm. Why? Throwing a new language at the problem is unlikely to solve
anything directly. Yes, there are certain interfaces which would benefit
from built-in class handling functionality from a language, but these are
just as likely to benefit from C++ or Smalltalk than from Java. I think you
are betraying your biases here rather than providing a reasonable argument
as to *why* we would benefit from using Java in particular. And, as you point
out, some of the low-level bit-fiddling that we do (and there's a lot of it)
along with the WAP stack material, and the serial interface handling stuff
is going to be more difficult in Java than in C.
There are countless other issues with a change of language at this stage,
though I'm certainly not absolutely sold on C as such. If you can provide
a reasonable defence of why Java as such is going to rock our respective
worlds, then I'm all ears.
> It may also be desirable to leverage the
> gnokii work, although I confess I don't know gnokii in detail.
Gnokii is GPL. Kannel is BSD. Using gnokii is entirely undesirable.
> Each layer should expose either an XML and Java object interface (or both),
> so it should be possible to use just the lower layers, if a custom
> application is required, or equally, it would be possible to easily write
> additional smsc modules conforming to the same API.
These are good architectural suggestions, obviously my previous Java comments
still holding.
> We should aim to make this son-of-Kannel, the reference implementation of
> emerging messaging standards. We should also encourage smsc vendors, (Nokia,
> Sema, Logica, etc) to contribute the smsc modules. It should be covered by
> either a Gnu licence, or better, the Java Community Process.
Well, vendors are more than welcome to contribute as it stands. Though,
strangely, they don't appear to be particularly interested, most likely because
of the ridiculous sums of money they charge for their own proprietary solutions.
The Kannel community has expressed little interest in a change of license, and
consequently if you want to change the license, you'll have to go it without
their support.
> Note the absence of WAP. If anybody actually cares about WAP, the WAP
> components should be taken out and recast as a discrete product. The
> original premise that WAP and SMS sit within a common stack is not likely to
> happen in the real world, and I sense that the two differing applications of
> Kannel are tripping over each other.
This is a valid criticism. Splitting the WAP and SMS components completely has
definite advantages. Basically, at this stage, we have the following material;
1) Software load-balancer (bearerbox)
2) WAP Gateway (wapbox)
3) SMS Gateway (smsbox)
and there may be certain advantages to this approach (and splitting it up
accordingly into those sub-projects).
See ya,
Nick
--
Nick Clarey, System Architect | "Sometimes when you fill a vacuum,
3G LAB | it still sucks." - Rob Pike
ph 44-1223-478900 fax 44-1223-478901 |
