[asterisk-dev] [Code Review]: AMI version 1.4 Specification Review Request

[Matt Jordan]

> On Jan. 8, 2013, 9:11 a.m., elguero wrote:
> > Based on a quick look, I like it! The documentation is very clearly written.
> > 
> > Just a few thoughts:
> > 
> > Tags - My first thought was that multiple tags should not be on separate lines, like in the example provided for sip peers in sip.conf.  Generally, one would think that the first tag would be overwritten by the second tag.  What about a comma delimited list and then we could call that setting "tags" instead of "tag" (tags=special_endpoints,endpoint_group_one).  I can just picture somebody putting tag towards the top of a peer definition and then another one later on and not figuring out that they have multiple tags and wondering why they are getting messages that they shouldn't be getting.  Just throwing that out there.
> > 
> > Keys - Keys are case insensitive.  Why not case sensitive?
> > 
> > Port and bindaddr - Why don't we combine these to one setting, bindaddr?  We are doing that for tlsbindaddr and I believe other parts of Asterisk do this now too.
> 
> Sean Bright wrote:
>     > Keys - Keys are case insensitive.  Why not case sensitive?
>     
>     I tend to agree.  I would always err on the side of being too strict, rather than accommodating, especially when we aren't dealing with direct user input (a person typing at a keyboard).

Tags: I'm good with tag_a,tag_b as the mechanism to specify multiple tags.

Port and bindaddr: Sure.

Case sensitivity: this is a tough one. In general, I favor case sensitivity as well (particularly in the domain of programming languages, when an interpreter or compiler exists to aid you). However, in this case I'd make a motion for case insensitivity on a few grounds:
1) Many AMI libraries already assume case insensitivity (StarPy) comes to mind. While library compatibility is not sufficient reason for a decision in this case (after all, the purpose of a specification is to hopefully get the basic rules *right*), it is something to keep in mind.
2) When dealing with an interface protocol, it's often best to be as forgiving as possible. Third party systems often get things wrong - witness, for example, ASTERISK-20897.
3) Keys that are case insensitively identical are highly unlikely to have different semantics. An action that includes both 'Channel' and 'channel' - with different meanings - is unlikely to ever be accepted. If it is not acceptable to have actions/events with case insensitive fields, why require case sensitivity?


- Matt


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


On Jan. 8, 2013, 8:41 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2269/
> -----------------------------------------------------------
> 
> (Updated Jan. 8, 2013, 8:41 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> A proposed revamp of the AMI protocol has been written and is available for discussion:
> 
> https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification
> 
> Please note that this will change the AMI protocol significantly, and represents a major shift in how the protocol represents operations in Asterisk to consumers of the protocol.
> 
> 
> Diffs
> -----
> 
> 
> Diff: https://reviewboard.asterisk.org/r/2269/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130114/c5b066e1/attachment.htm>