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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello
On 3/14/13 5:54 PM, Peter Dunkley wrote:
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]?
Looking at the other files, I would do it with underscore instead of dash, but I don't have really any strong preference.
Cheers, Daniel
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev