Stipe Tolj wrote:
> agreed. Which indicates again the need for an module API that would
> "allow" people implement Kannel module filters without the need to
> maintain them in Kannel's source core.
>
> So heads up on who does proposals for the (at least wapbox specific)
> module API! ;)
I suspect Kannel needs some cleanup for this to work properly. Currently
each protocol entity (e.g. application layer, WSP, WTP,...) contain a lot
of redundant code:
They provide an external interface, to init, cleanup and handle events and
then do a lot of things by hand that should be hidden inside a protocol
framework (e.g. create event queues, disptach events...).
This has two drawbacks:
1.) The current approash "One thread for every entity" is hard coded into
every entity (because it starts its own thread). Using an event driven
state machine for all entities involves major surgery.
2.) It's difficult to write a clean interface that would allow new entities
in the system (e.g. the wished for plugins).
Proposal:
Separate the protocol framework from the protocol implementation. This means
that a protocol entity would export its interface while the framework is
responsible for running the entities when needed and do the housekeeping
work of dispatching events.
Example:
typedef void (*init_func)(some argiments here);
typedef void (*dispatch_func)(WAPEvent *event);
typedef void (*shutdown_func)(void);
struct kannel_entity {
init_func init;
dispatch_func dispatch;
shutdown_func shutdown;
};
Then inside the entities do:
struct kannel_entity WSPEntity = {
.init = WSPInit,
.dispatch = WSPDispatchEvent,
.shutdown = WSPShutdown
};
Inside the main file one would do something like this:
kannelframe_register_entity (&WSPEntity);
kannelframe_register_entity (&WTPEntity);
kannelframe_register_entity (&WAPEntity);
External modules could be added the same way. They would probably need some
way to specify where to hook into the system to filter events.
The advantage would be that one implementation for the protocol framework
could use the current approach "One thread per entity" while another one
could use a single threaded state machine without the need to modify the
actual entity implementation.
Regards
Joerg
