[Kamailio-Users] kamailio 1.5 and beyond

[Henning Westerholt]

Hi all,

i want to share some thoughts where i think the priorities for the next major
release(s) of Kamailio should be. This is the continuation of the work i (and
many others) have done for the previous releases, but i thought it makes sense
to summarize it a bit on a higher (abstraction) level. 

1. Refactoring and cleanup

We still have quite a lot of old code in our repository, which is no longer
working or obsolete. Some implementations uses way to much gotos, or macros
that are several pages long. This makes important parts of the core and 
modules harder to understand and maintain then necessary. Especially in the 
area of utility functions there is still to much duplicated code.

proposed actions:

- identification and removal of no longer working code in the core and modules
- identification and unification of redundant (duplicated) code in core and 
  modules to one implementation
- identification and removal of obselete code parts in core and modules.
- refactoring of code to use less gotos and macros

2. User and developer documentation 

With regards to user documentation quite a lot of work has been done in the
past releases. But with the developer documentation, especially in certain
modules, there is still plenty of content missing. As the involvement of
individuals and companies can change, documentation is necessary to ensure a
continued maintenance of the code.

proposed actions:

- conversion of already existing documentation to doxygen format
- add a short doxygen module definition to every module, explaining the 
  purpose
- add a short doxygen file definition to every file, explaining the purpose
- extend doxygen docs in important areas like the core and modules like TM
- autogeneration of database related module documentation from the XML scheme 
  definitions

3. Consolidation in core and modules

At the moment we've 85 modules in our repository. Some modules implement only
one or two functions, which makes no real sense with regards to the
maintainance overhead that comes with it. 24 of the modules are using database
access and 7 implement database interfaces. There is no clear boundary in some
areas of the core and modules, this hinders the further development of the
server.

proposed actions:

- integrate several modules that share responsibilities and not implement that 
  much functionality on their own into one
- autogeneration of module interface and database infrastructure code from the 
  XML database scheme definitions
- identify obselete module functions that can be done easily with 
  pseudo-variables now. Remove these functions.
- move certain core parts that do not need to be there into modules, making 
  the core smaller and more flexible
- identify core APIs which are used from modules, evaluate eventual 
  generalisations to make the modules less dependent from the actual core
  implementation

4. Quality assurance

The complexity of several modules, and the special dependencies that some of
them carry increase the work to test the server and reproduce bugs. Without
proper test coverage maintenance work is slowed down and flexibility is lost. 
All "easy" bugs that get caught automatically will not reach the user, 
increasing the quality.

proposed actions:

- extend available test suite to cover more of core and modules
- continue maintenance of available infrastructure for build tests (build bot, 
  debian package autobuilder), evaluate extensions to increase coverage

All this work will be done as in the past in an open and accountable way on 
the developer list. For bigger changes a request for comment will be posted 
in advance on this list. If existing functionality is deprecated, then this 
RFC will be also posted to the user list. If some functionality is moved or 
changed than this will be documented in the wiki (porting docs) as usual.

I understand some changes will be probably add work on your side, in porting,
configuration adjustments and the like. But i think this is necessary to 
ensure the further development of the Kamailio project, and to be able to 
deal with new challenges that will come up in the future. 

Any input and help with this regards to this individual tasks is of course 
much appreciated. In the end the success of the project depends in the future 
(like it did in the past) on your support. Without your involvement in 
contributions, discussions and bug reports i would be only to a much lesser 
extend involved in this project.

Thank you,

Henning Westerholt


-- 
Henning Westerholt - Development Consumer Products / DSL Core
1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany