Differences

This shows you the differences between two versions of the page.

--- devel:xavp [2009/05/27 21:54]
miconda created
+++ devel:xavp [2009/07/28 13:09] (current)
82.113.121.84
@@ Line 3: / Line 3: @@
 <code>
 Proposal and prototype implementation by:
-   Daniel-Constantin Mierla <miconda [at] gmail (dot) com
+   Daniel-Constantin Mierla <miconda [at] gmail (dot) com>
+CODE IN GIT REPOSITORY BRANCH: daniel/xavp
 </code>
 ===== Purpose =====
+It is not a replacement for current AVP implementation, but a new feature (a new data structure available in code and config, similar to pseudo-variable like: sahred variable $shv(...), hash table variable $sht(...), private variable $var(...)). Developers and script writers can decide which one to use: AVP or XAVP.
+Primary goals:
   * ability to store more value types, not only integer and string
   * simplify addressing by using only string name for attributes
   * 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 stateful processing, during the lifetime of transaction
 ===== Internal design =====
@@ Line 72: / Line 79: @@
 </code>
-==== Generic data value ====
+=== Generic data value ===
 It allows to store any type of data built in shared memory. A structure of **sr_data_t** has to be allocated in shared memory and filled with two fields:
   * **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()**
+  * **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):
@@ Line 118: / Line 125: @@
 NOTE: this avp printed to xlog will return a string: <<data:value of the pointer to data>> (e.g., <<data:0x973937393>>), good for debug purposes.
-==== XAVP data value ====
+This type of value is intended for internal usage, one of the modules that needs it immediately being **dialog**.
+=== XAVP data value ===
 This allow to store within an xavp another xavp or list of xavps.
@@ Line 173: / Line 182: @@
 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=>uri)="sip:10.10.10.10";
+$xavp(sf[0]=>fr_timer)=10;
+$xavp(sf[0]=>fr_inv_timer)=15;
+$xavp(sf[0]=>headers)="X-CustomerID: 1234\r\n";
+$xavp(sf=>uri)="sip:10.10.10.11";
+$xavp(sf[0]=>fr_timer)=20;
+$xavp(sf[0]=>fr_inv_timer)=35;
+$xavp(sf=>uri)="sip:10.10.10.12";
+$xavp(sf[0]=>fr_timer)=10;
+$xavp(sf[0]=>fr_inv_timer)=15;
+$xavp(sf[0]=>headers)="X-CustomerID: pw45\r\n";
+</code>
+For second destination, there is no extra header to be added. With current avp model, a dummy value must be set, otherwise the value from third destination will be used.
+  * **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 "dispatcher". Inside that list it can have xavp with names: dst, grp, cnt. In the global list or other sublists can be other avps with name 'dst', without any interference.
+  * **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 "dispatcher" via modparam, while the names for AVPs dst, cnt, grp can be predefined and documented in readme.
+===== 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

Trace:

Differences

Navigation

Search

Toolbox

QR Code