[asterisk-dev] [Code Review] 2846: Finish conversion script from sip.conf to pjsip.conf

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2846/#review9859
-----------------------------------------------------------



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19054>

    As a global comment, please add pydoc comments to all public functions.



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19052>

    I'm not a fan of parameters that should be mutually exclusive coexisting.
    
    For example, it is invalid to call this function as follows:
    
    my_dict.get(my_key, from_self=False, from_templates=True, from_defaults=True)
    
    The fact that from_templates has priority over from_default can only be inferred from its order in the parameter list.
    
    While python doesn't really support enumerations, you can 'fake it' with class level attributes. Something like:
    
    class KeySource(object):
      OBTAIN_FROM_SELF = 0
      OBTAIN_FROM_TEMPLATES = 1
      OBTAIN_FROM_DEFAULTS = 2
    
    class Section(MultiOrderedDict):
    
      def get(self, key, key_source=KeySource.OBTAIN_FROM_SELF):
        ...
    
    And then throw an exception if the key source is not one of the allowed values.
    



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19055>

    This will add the elements in defaults to _defaults in reverse sorted order. So why not something like:
    
    self._defaults.extend(defaults.sort(reverse=True)
    
    
    Or exactly as add_templates was implemented.
    



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19056>

    I'm confused. Why do we reverse the sorted lists, then reverse them again when searching?



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19061>

    This should be a private function in MultiOrderedConfigParser



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19062>

    This is a utility function that is only called in a single place. Is there any reason not to just place it with or in section_by_type?



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19060>

    It feels exceedingly odd that these are public functions with no relationship to a class when the first parameter is always a MultiOrderedConfigParser. These should probably be a public functions on that class.



/trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py
<https://reviewboard.asterisk.org/r/2846/#comment19057>

    file is a keyword in Python and probably shouldn't be used as a variable name.
    



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19063>

    If there is more to do here, let's just make the issue and remove the comment.



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19064>

    We've done that :-)



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19066>

    This isn't needed.
    
    If foo and bar are both strings, this will work just fine:
    
    if foo in bar:



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19067>

    Remove is_in; use elif:
    
    if 'yes' in val:
    
    elif 'comedia' in val:
    
    ...



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19068>

    Same here



/trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py
<https://reviewboard.asterisk.org/r/2846/#comment19058>

    This can just be pjsip.write()


- Matt Jordan


On Sept. 26, 2013, 9 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2846/
> -----------------------------------------------------------
> 
> (Updated Sept. 26, 2013, 9 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22374
>     https://issues.asterisk.org/jira/browse/ASTERISK-22374
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This finishes off the initial work on the conversion script from sip.conf to pjsip.conf. This addresses missing endpoint options, registration options, auth options, and transport options.
> 
> I ran the flake8 checker on the files, but I only corrected its complaints in the new sections I added in order to keep the diff reduced to the relevant changes. Unfortunately, this ended up being moot since I renamed the files and the directory that they are in.
> 
> 
> Diffs
> -----
> 
>   /trunk/contrib/scripts/sip_to_pjsip/astdicts.py PRE-CREATION 
>   /trunk/contrib/scripts/sip_to_pjsip/astconfigparser.py PRE-CREATION 
>   /trunk/contrib/scripts/sip_to_pjsip/sip_to_pjsip.py PRE-CREATION 
>   /trunk/contrib/scripts/sip_to_res_sip/astconfigparser.py 399909 
>   /trunk/contrib/scripts/sip_to_res_sip/astdicts.py 399909 
>   /trunk/contrib/scripts/sip_to_res_sip/sip_to_res_sip.py 399909 
> 
> Diff: https://reviewboard.asterisk.org/r/2846/diff/
> 
> 
> Testing
> -------
> 
> Tested against various sip.conf files to ensure that generated sections had the expected data in them.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130930/94335315/attachment-0001.html>