Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| devel:xavp [2009/05/27 19:55] – miconda | devel:xavp [2009/07/28 11: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 77: | Line 84: | ||
| * **p** - pointer to your data - the data must be also allocated in shared memory | * **p** - pointer to your data - the data must be also allocated in shared memory | ||
| - | * *pfree** - function to free the data - it takes two functions as parameter - void pointer to data and a free function. The free function is provided by the core API, because depending on usage case it might be **shm_free()** or **shm_free_unsafe()** | + | |
| Example of usage (c-like pseudo-code): | Example of usage (c-like pseudo-code): | ||
| 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 173: | Line 182: | ||
| When getting the value, no index or [0] point to same xavp - first one with respective name. | When getting the value, no index or [0] point to same xavp - first one with respective name. | ||
| + | ===== Benefits ===== | ||
| + | |||
| + | * **grouping of value based on purpose** | ||
| + | * for example, avps for serial forking: | ||
| + | |||
| + | <code c> | ||
| + | $xavp(sf=> | ||
| + | $xavp(sf[0]=> | ||
| + | $xavp(sf[0]=> | ||
| + | $xavp(sf[0]=> | ||
| + | |||
| + | $xavp(sf=> | ||
| + | $xavp(sf[0]=> | ||
| + | $xavp(sf[0]=> | ||
| + | |||
| + | $xavp(sf=> | ||
| + | $xavp(sf[0]=> | ||
| + | $xavp(sf[0]=> | ||
| + | $xavp(sf[0]=> | ||
| + | |||
| + | </ | ||
| + | |||
| + | For second destination, | ||
| + | |||
| + | * **faster lookup** | ||
| + | * with current avp, getting to last avp (as in above example) would require 11 steps in iteration. With xavp it takes 7 steps. When dealing with lot of avps, the improvement is more significant if the grouping is used. | ||
| + | * from inside the code, the improvement is more visible, as the reference to inner xavp list can be kept at first lookup. | ||
| + | |||
| + | * **further improvements to speed and flexibility by storing generic data structures** | ||
| + | * example: serial forking function can build now the info in a shared memory structure | ||
| + | |||
| + | * **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 " | ||
| + | |||
| + | * **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 ===== | ||
| + | |||
| + | Couple of use cases I have in mind now: | ||
| + | |||
| + | * **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 | ||
| + | * **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 | ||
| + | * 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 | ||