Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
devel:xavp [2009/05/27 22:35] miconda |
devel:xavp [2009/07/28 13:09] (current) 82.113.121.84 |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| < | < | ||
| Proposal and prototype implementation by: | Proposal and prototype implementation by: | ||
| - | | + | |
| + | |||
| + | CODE IN GIT REPOSITORY BRANCH: daniel/ | ||
| </ | </ | ||
| ===== Purpose ===== | ===== Purpose ===== | ||
| + | It is not a replacement for current AVP implementation, | ||
| + | |||
| + | Primary goals: | ||
| * ability to store more value types, not only integer and string | * ability to store more value types, not only integer and string | ||
| * simplify addressing by using only string name for attributes | * simplify addressing by using only string name for attributes | ||
| * possibility to optimise the search by creating lists of xavp lists | * possibility to optimise the search by creating lists of xavp lists | ||
| * availability in config file for xavp with string or integer value (expression interpreter supports only these values) via PV module | * availability in config file for xavp with string or integer value (expression interpreter supports only these values) via PV module | ||
| + | * availability in stateful processing, during the lifetime of transaction | ||
| ===== Internal design ===== | ===== Internal design ===== | ||
| Line 117: | Line 124: | ||
| NOTE: this avp printed to xlog will return a string: << | NOTE: this avp printed to xlog will return a string: << | ||
| + | |||
| + | This type of value is intended for internal usage, one of the modules that needs it immediately being **dialog**. | ||
| === XAVP data value === | === XAVP data value === | ||
| Line 206: | Line 215: | ||
| * **less exposure the name conflicts by grouping** | * **less exposure the name conflicts by grouping** | ||
| * modules can group their internal AVPs under a xavp, so other xavps with same name in global list won't affect the module functionality. Say dispatcher groups its avps under " | * modules can group their internal AVPs under a xavp, so other xavps with same name in global list won't affect the module functionality. Say dispatcher groups its avps under " | ||
| + | |||
| + | * **reduce number of parameters for some modules** | ||
| + | * a module can reserve now only one name for xavp in default list. Inner xavp can have predefined names, without the risk for overlapping with other modules or config | ||
| + | * **dispatcher** module can reserve xavp name " | ||
| ===== Use cases ===== | ===== Use cases ===== | ||
| Line 212: | Line 225: | ||
| * **acc** module for multi-leg accounting - grouping will improve speed and remove the wrong behaviour when a value is not set in one leg - null is set for the right leg, not for the last one. | * **acc** module for multi-leg accounting - grouping will improve speed and remove the wrong behaviour when a value is not set in one leg - null is set for the right leg, not for the last one. | ||
| - | * **dispatcher** module - grouping | + | * **dispatcher** module - grouping |
| + | * **dialog** module - store using generic data structure the dailog context pointer (get rid of current hack that adds a fake callback structure) | ||
| * serial forking functions | * serial forking functions | ||
| + | * possible in **lcr** or **carrierroute** | ||
| + | * possible in **utils**, to store each line of http response in a grouped xavp list. | ||
| + | |||
| + | ===== Observations ===== | ||
| + | * it is not a replacement to existing AVPs, but an addition, a new class of pseudo-variables | ||
