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?]
