<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'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'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'd prefer to just define that keys don't contain ':'. Values can contain a ':' without error, as the end of a value is denoted by '\r\n'. Values should not contain '\r\n'. The problem with trying to handle these kinds of escaping issues with the current syntax as that we'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's breaking existing implementations, and then there'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 "ChannelVars({channel_name}): value" 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 "ChannelVars1","ChannelVars2" could have been used and - while silly - would at least be consistent with "Channel1", "Channel2".
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'd be better served by just supporting JSON/XML instead.</pre>
</blockquote>
<p>On February 7th, 2013, 9:55 a.m., <b>Ben Langfeld</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;">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'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>
</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;">I totally agree that if we were writing AMI from scratch, we wouldn't have ended up on the current syntax. Such is hindsight.
Unfortunately, that's not the case. The aim here is to make AMI easier and more consistent, not take everyone's existing libraries and burn them to the ground. Luckily, the fact that AMI is being built on top of Stasis Core (which is not going to use strings as its mechanism of pushing state information) - and is no longer a direct reflection of all of the implementation details in Asterisk - means that building something else that provides XML or JSON becomes much easier.</pre>
<br />
<p>- Matt</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>