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