Hi,
Here's some comments;
> this is a unique ID your application specifies. It will be sent back
> to you when the delivery report arrives so it should be something
> like a message numer or so.
How do you ensure unique IDs across applications ? ie. What if application
A and application B are both using the same sendsms interface and are
specifying identical IDs ?
> Thats how far it is requesting it.
> The messages are sent out to the SMSC and at some point in time the
> DLR arrives back from the SMSC. In that case, a incoming SMS is
> generated and sent back. This incoming SMS is constructed the
> following way:
How are the generated incoming SMS messages routed back to the correct
SMS box ? If you have 3 SMS boxes connected, each submitting messages
requesting DRs, how does the bearer box know which SMS boxes to routes
the individual DRs to ? (If I've missed the obvious, sorry).
> a) We want to use some kind of database instead of using a list in
> memory. This doesnt work well if its having a lot of delivery
> reports. Of course this introduces an additional library to kannel.
Why don't you use the bb_store.c functionality ? If you represented a DR
as another option in the Msg struct, it should'nt be too hard to sit on
top of the functionality offered by the existing store. Given that the
store is there to support correlation of Msgs and internal Acks, it
seems a logical choice.
>
> b) if we use memory, we want to save it to disk from time to time
> (especially at shutdown) and reload it at startup.
Again, this is functionality in the store.
>
> c) We want to clean the list from too old entries
The store includes a background thread, performing correlation. It could
be extended to do timeouts for DRs (or a new thread introduced).
I think there are two broad approaches to DRs.
1. Applications that want to handle the DR themselves and hence expect the
gateway to handle it as a message (ie. transparently).
2. Application that want to know the information contained in the DR and
hence expect the gateway to supply that information in response to a
query.
As I understand your patch, its roughly case 1 ?
I don't think your DR representation is rich enough;ideally you should carry
as much information as possible back to the originating application to
allow it make a decision on how to handle the DR. I would prefer a Msg
based representation to lever on the existing store functionality as stated
above. I also think this approach makes it easier to deliver case 2 as this
code evolves.
Hope this hopes and well done for starting the work.
