This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
devel:kamailio-5.0-design [2016/02/24 23:20] miconda created |
devel:kamailio-5.0-design [2016/02/28 11:50] miconda |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Kamailio v5.0 Design ====== | ====== Kamailio v5.0 Design ====== | ||
+ | |||
+ | ===== Overview ===== | ||
After 15 years of development, | After 15 years of development, | ||
+ | |||
+ | This page collects suggestions and ideas for major refactoring of various components to make the leap to v5.0. | ||
+ | |||
+ | When adding a remark that needs to be tracked by author, use initials in front of the paragraph. The list of contributors to this document and initials: | ||
+ | |||
+ | * Daniel-Constantin Mierla (dcm) | ||
+ | |||
+ | ===== Initial Remarks ===== | ||
+ | |||
+ | Initial content for this document is listing also ideas popped up during discussions at Fosdem 2016 and Kamailio Development Workshop - among participants: | ||
===== Configuration File ===== | ===== Configuration File ===== | ||
+ | |||
+ | Goals: | ||
+ | |||
+ | * have at least one option of an optimized configuration file interpreter targeting high performance SIP routing deployments | ||
+ | * have at least one option of a more flexible configuration language that allows: | ||
+ | * extended language syntax | ||
+ | * reloading routing rules at runtime | ||
+ | |||
+ | To achieve the above, following sub-sections collects the proposals for configuration file language. | ||
+ | |||
==== Exporting Functions To Embedded Interpreters ==== | ==== Exporting Functions To Embedded Interpreters ==== | ||
Line 30: | Line 52: | ||
* cmake | * cmake | ||
+ | ===== Continuous Integration ===== | ||
+ | |||
+ | Goals: | ||
+ | |||
+ | * attempt to make a more consistent and "easy to contribute to" continuous integration eco-system | ||
+ | |||
+ | |||
+ | ==== Unit Test Framework ==== | ||
+ | |||
+ | Reviving the exiting unit testing or selecting another framework. | ||
+ | |||
+ | ==== Minimal Unit Tests ==== | ||
+ | |||
+ | Defining a minimum set of automatic tests that needs to be provided by each module: | ||
+ | |||
+ | * a minimal config for loading the module, to be sure it doesn' | ||
+ | * can be done with a config as simple as: | ||
+ | |||
+ | < | ||
+ | |||
+ | loadmodule " | ||
+ | |||
+ | request_route { | ||
+ | ; | ||
+ | } | ||
+ | </ | ||
+ | * or can require setting some module parameters or even loading other modules |