28 Jul
2009
28 Jul
'09
11:51 a.m.
Daniel-Constantin Mierla wrote:
- possibility to store more data types - AVP allow string and integer
data types. More can be handled by XAVP, including a generic data type
where you can build your own structure and store it in the list. This is
good for example to store custom structures for transaction lifetine --
right now dialog module needs to store reference to dialog structure.
Optimizations can be done for any case of serial forking -- uri, dst
uri, q, etc can be stored in a structure without a need to parse and
build it from an encoded value stored in one or many avps
You could generalize this into only using the generic data value and
wrap the other types into these. This requires makeing these generic
data values in the script language somehow. For all this, you will need
a somewhat more elaborate interface to the type than a free function.
I suppose you could define a struct much like the module struct that
contains a bunch of pointers to various functions for various things. An
instance of this type then consists of a pair from the pointer to the
type struct (which incidentally is uniquely identifying the type and a
pointer into shared memory pointing to the value).
- possibility to group XAVPs inside another XAVP -
practically is
building lists of XAVPs.
If you wrap this into a generic type, you can have various types for
lists and maps and whatnot (although this should really do). There are
some questions around references vs. copies here, so this will probably
go off into reference counting and stuff.
Although, neatly enough, this can probably made in such a way that XAVPs
get auto-magically destroyed when their parent object (the transaction,
dialog, etc.) is being destroyed.
Regards,
Martin