Hi Daniel,
Thanks for the information.
I already have "parse_require.[ch]" and "parse_supported.[ch]", so the
question is what to call the options-tag.[ch] files which, in and of
themselves, need to be used by the parse_XYZ.[ch] files rather than
directly. Does it make sense to call these parse_options-tag.[ch]?
Regards,
Peter
On 14/03/13 16:46, Daniel-Constantin Mierla wrote:
Hello,
you can move to the core as long as it is licensed as BSD contribution
-- it should be no problem/conflict with parse_supported from kcore,
it was on my todo list, as I spoke with Andreas some time ago and he
agreed to this change.
My only suggestion would be to keep the common pattern on file name
for parser/*, thus naming the new file parse_XYZ.{c,h}
Cheers,
Daniel
On 3/14/13 12:57 PM, Peter Dunkley wrote:
Hello,
I have been working on some outbound related fixes (problems
identified by Olle during SIPit). Some of these require me to parse
the "Require:" header.
There is already a parser for "Supported:" in "lib/kcore" and the
parsing for "Require:" is almost identical. To this end I have
abstracted a lot of the code from "parse_supported.[ch]" into new
"options-tags.[ch]" files and have a much shorter
"parse_supported.[ch]" and "parse_require.[ch]" that use the
options-tags parser.
Another advantage of this is that it will simplify the writing of
proper parsers for other similar headers in HTTP (for example, the
"Sec-WebSocket-Protocol:" header used during the WebSocket handshake.
Now that I've done this I would like to move these parser files from
"lib/kcore" into "parser". Is there any reason I shouldn't do
this?
The code can be found in the pd/outbound branch.
Regards,
Peter
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev