On 19/09/03, Stipe Tolj ([EMAIL PROTECTED]) wrote:
> Rory Campbell-Lange wrote:
> > Another note is that some people may wish to keep a record of their
> > dlrs and not have them deleted by default. I patched dlr.c to call
> > update on delete rather than delete, which meant that the dlr status
> > is recorded in the dlr table.
>
> hmmm, we didn't intend this inside the DLR storage itself. You will
> have a "DLR SMS" inside your access log file for it, so it will be
> recorded.
>
> IMO, you should not keep these inside the temporary storage space of
> the DLRs.
I can see this makes sense. In this scenario I imagined Kannel would
"find" messages waiting to be sent from the database and then update the
record with a delivery report. Incoming messages would be added to the
db. This would move the HTTP interfaces out of Kannel and mean that the
HTTP interfaces would be to the database itself, leaving Kannel to focus
on delivery and status reporting.
Some of the projects I work on have this architecture and it works well
if you have a database system (like Postgresql) that allows transactions
and so on. By writing simple procedural pl/sql interfaces to the
database you can keep a constant set of database interfaces while both
programs might changes.
For instance
select messages_update(200345, 1, 0);
might set the delivery status of row 200345 in messages to sent, allow
the record to be deleted and update stats in the smsc table and sent a
notification to the sender...
Sorry -- this has got off topic.
Kind regards
Rory
--
Rory Campbell-Lange
<[EMAIL PROTECTED]>
<www.campbell-lange.net>
