29 Jul
2009
29 Jul
'09
1:49 p.m.
On 29.07.2009 11:52 Uhr, Martin Hoffmann wrote:
Daniel-Constantin Mierla wrote:
the core has to provide at least the mechanisms to hook up to different
contexts (e.g., like now to sip message/transaction). The PV interface
implementation is done in pv module, so that is not bound to core at
all. Without pv module, xavp cannot be used from config.
To the other matter, I brought this to discussion to find the best
solution, therefore all is open. There is no memory penalty as the value
is a union, if one uses only the generic data it is not affected by the
existence of the other simple data types.
I am not a fan of over-engineering, trying to keep being practical, not
getting to something very complex due to nature of variables existing
now, in kamailio (at least) there are references inside the sip message,
to the proxy and OS environment, to shared and private memory, list of
values in share memory (avps), database query result, hash table (local
cache), memcached data (distributed cache). What is common to all these
is the interface to config file -- each exports set/get function to/from
int or str values.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
On 28.07.2009 13:51 Uhr, Martin Hoffmann wrote:
Agree. I was actually more thinking into the future and into a Grand
Unified Variable kind of thing. Not sure if this should be a service
provided by the core or some module. But should we agree that we want
such a thing then it might be better to work on that instead of building
an interims solution based on AVPs.
This is not to diminish your work in any way, I quite like the
possibilities especially with the option for lists. It just may safe you
same work that will eventually be superseded by something else.
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.
it is an option, but I wanted to have it simple for common data types in
the same time to allow dealing with more complex structures.