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