> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> Andreas Fink wrote:
> >
> > I think your whole approach is wrong. You should do this kind of
> > thing in a separate application. You then can link this separate
> > application to gwlib and use gwlib's HTTP library function
> to deliver
> > your messages from the database on to kannel. This will make your
> > code much more portable, you dont have to mess with all the
> internals
> > of Msg * and your code works with multiple SMSC types.
>
> Andreas is right here. We try to avoid muggling external APIs into
> Kannel as much as possible. For some reasons it's necessary as
> permanent storage backend, like DLRs.
>
> But for batched SMS transmission out of a database you should use an
> external component that queries your db and talks HTTP to Kannel's
> interface in this way:
>
I don't totally agree here - offering an API for "sms-service"
development to support different types for sms delivery from and
submittion to smsbox is a "good idea (tm)" IMO, and a module to store
and query from a database is a valid solution for integrating kannel
into an application. this being said, the API should be exposed by
sms/wap box and not by bearerbox. I remeber some talking on the list
about a pluggable dynamic loading API for sms-service a while back, I
wonder what came out of it.
> -----------------------------------------
> Ok, I understood and I have already started to develop an
> application that works as
> you said.
> But you see, my point is to build an application which is
> easy to maintain. In case
> you use HTTP, you need to start bearerbox, smsbox plus
> external application that
> querries the database. You see, there are at least 4 connections
> SMSC < - > bearerbox
> bearerbox < - > smsbox
> smsbox < - > http server
> http server < - > database
> It is a greater probability that something goes wrong in this
> case (4 connections
> may broke). My sollution is to use only 2 connections:
> SMSC <-> bearerbox
> bearerbox <-> database
I don't agree here - stability isn't controlled by the number of
connection, but by the complexity of each part of the system. by keeping
the parts seperate and relativly simple you get better stability, by
integrating everything but the kitchen sink into a single executable (or
two) you decrease stability considerably.
The benefits from this multiple parts design is that is one sub-system
crashes, it is relativly easy to restart it (often automaticly) w/o
affecting the rest of the system. with good queueing, your service can
stand a down time of even a few minutes of several sub-systems w/o a
noticable effect on the users.
> -----
> I started writing an application with your sollution and I
> have to solve one
> problem:
> I need to get the message id (gived by SMSC) to write it in
> the database. If I have
> this id, then I can update the line corresponding to a
> message when a DLR arrives.
> How can I get this id via smsbox (http) ?
> And how can I write a DLR in a postgresql database?
That's the first mistake made by any new application developer for
Kannel, so don't worry about it :-) you don't need the message ID from
the SMSC ,you just need to know the status of the message as it changes,
right ? that's what the internal DLR mechanism of Kannel is for - when
you send a message, add the dlrmask and dlrurl parameters and a call
will be made to the dlrurl you supplied whenever the status of the
message is changed in a way as to match dlrmask.
--
Oded Arbel
m-Wise Inc.
[EMAIL PROTECTED]
(972)-67-340014
(972)-9-9581711 (ext: 116)
::..
Customs official: "Do you have anything to declare, sir?"
Avi: "Yeah. Don't go to England."
-- "Snatch"
