[sr-dev] Parsing requires and supported in modules

[Peter Dunkley]

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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>