Re: wapbox -- support for external filters

Hi!

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

Well, but this still needs some interface for running external
programs, right?

You'd have to define ordering on those kannel_entities... Are they
needed at other place than format conversions?
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]