For Asserted and preferred identities, we don't need to parse the content, but in other headers I have not gotten to yet, we may need to.
Please help me understand, I would have thought from an architecture perspective, we would populate the sip_msg structure with all possible sip headers as well as the parsers. What is the reason we don't do this currently? performance?
Cheers
Jason
On Wed, Nov 2, 2011 at 5:37 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
Hello,
do not forget that we have internal libraries, if you have code
shared by several modules but it is not for general interest to be
stored in core. It is better than using defines, IMO. Users take
usually what is given by default, it is rarely when people compile
with different flags and providing a feature that requires this will
make testing harder and adoption slower.
For example, even now there are some parser extensions in lib/kcore/
(which I plan to move to core, btw, since there were left there by
the integration process).
Just a clarification for myself, I guess you mean parsing the
content of IMS specific headers, since there is a generic parser for
any kind of header, that will give the header name and body.
If the headers must be accessible by several modules, then
it would
make sense to have them into existing framework.
One option would be to enable some compile flags and compile
that code
only for IMS (similar to FLAVOUR - we could add a new
flavour)
don't know if I would go so far as to call it another
'flavour' (semantically), but yes compile flags may be the
way to go......