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/
-------------------------------------------------------------------
