<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/2269/">https://reviewboard.asterisk.org/r/2269/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On January 8th, 2013, 2:57 p.m., <b>tim_ringenbach</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">In section 4.2, I&#39;d like to see the message format spelled out a little bit more. What characters are allowed in the key, and in the value? Is there any escaping mechanism for embedded new lines, or colons in the key? I&#39;m also thinking about this bug I filed a while back:  https://issues.asterisk.org/jira/browse/ASTERISK-20369</pre>
 </blockquote>




 <p>On January 13th, 2013, 9:45 p.m., <b>Matt Jordan</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">In general, I&#39;d prefer to just define that keys don&#39;t contain &#39;:&#39;. Values can contain a &#39;:&#39; without error, as the end of a value is denoted by &#39;\r\n&#39;. Values should not contain &#39;\r\n&#39;. The problem with trying to handle these kinds of escaping issues with the current syntax as that we&#39;re going to end up creating mechanisms that exist in better forms of syntax (be it something akin to URI encoding, CDATA tags, or what-have-you), and if we do that, we might as well just drop-kick the current syntax into the trash can and use XML or JSON. Part of me is inclined to do that, but there&#39;s breaking existing implementations, and then there&#39;s setting them on fire and watching them burn. I was going for the former rather than the latter :-)

On to the channelvars setting...

I think using the nomenclature &quot;ChannelVars({channel_name}): value&quot; was probably a mistake. First, the channel name is usually complex and only obtained once a NewChannel event is received. Using a value in an event to parse out keys in the same event feels wrong. If the reason for using this nomenclature was for events that contain multiple channels, the nomenclature &quot;ChannelVars1&quot;,&quot;ChannelVars2&quot; could have been used and - while silly - would at least be consistent with &quot;Channel1&quot;, &quot;Channel2&quot;.

tl;dr: we should define more explicitly how to parse a line in an action/event; re-think ChannelVars entirely; and not try to kill ourselves too much on the syntax since we&#39;d be better served by just supporting JSON/XML instead.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Support for JSON or XML (or frankly anything for which I can steal a parser rather than write one) would be very much appreciated, even if it&#39;s not the default format. Adhearsion/Punchblock currently uses JSON payloads on FreeSWITCH EventSocket and this works great. It would be nice to be able to throw away our 7 year old AMI parser which papers over all sorts of inconsistencies.</pre>
<br />








<p>- Ben</p>


<br />
<p>On January 8th, 2013, 8:41 a.m., Matt Jordan wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Matt Jordan.</div>


<p style="color: grey;"><i>Updated Jan. 8, 2013, 8:41 a.m.</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
  </td>
 </tr>
</table>





<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

</ul>

<p><a href="https://reviewboard.asterisk.org/r/2269/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>