J�rg Pommnitz wrote:
>
> 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.
sounds reasonable good J�rg. Could you try to make the pace and addopt
some of your concepts into the code to see how this would look like?
Stipe
mailto:[EMAIL PROTECTED]
-------------------------------------------------------------------
Wapme Systems AG
M�nsterstr. 248
40470 D�sseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:[EMAIL PROTECTED]
http://www.wapme-systems.de/
-------------------------------------------------------------------
