<br><div class="gmail_extra"><br><br><div class="gmail_quote">2012/12/1 Dan Jenkins <span dir="ltr"><<a href="mailto:dan.jenkins@holidayextras.com" target="_blank">dan.jenkins@holidayextras.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div><i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">We're going to start with fixing one of the most glaring problems with the current APIs: </span><a href="https://issues.asterisk.org/jira/browse/ASTERISK-20725" rel="nofollow" style="color:rgb(0,109,175);text-decoration:initial;outline:none;font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px" target="_blank">add a stable identifier to channels</a><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">, and use that identifier consistently throughout AMI. This solves a big problem for current AMI+AGI based applications.</span><b> - </b></i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><b>LOVE this!</b></span></div>
<div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><br></span></div></blockquote><div><br></div><div>This will be superb, but to do this it would be enough to add a new StableChannelID field to existing events :) and it would be even better if the user could supply it on Originate (like you do for AMI events), so you know from the start where events come from.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><i>Unfortunately, solving some of the larger problems would be very intrusive with the current API's, and introduce a host of breaking changes. Some are so fundamental, we would essentially be rewriting the interface. That's not acceptable; the current API's aren't going anywhere anytime soon. </i>- <b>Is there not scope to enhance these APIs? There was discussion a few weeks back on this mailing list about enhancing the AMI to support JSON/XML rather than key value return separated strings (After reading further down there is a line saying "</b></span><i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">AMI Event Structure</span><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"> - AMI events should be generated into a key/value object pair instead of the </span><tt style="color:rgb(51,51,51);font-size:13px;line-height:17.33333396911621px">printf</tt><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">-style string formatting currently used. This would allow Stasis to reuse the existing events.</span></i><b style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">" - Does this mean that the suggestion above needs to happen anyway?)</b></div>
<div><br></div></blockquote><div><br></div><div>I personally don't find it such a major thing to parse a set of blocks instead of only one, like e.g when you ask for a queue status. You could have a "LovesJson: true" line added on authentication and marshal results as Json instead of multiple blocks. In general the AMI could do with some brushing and cleaning, that's true.</div>
<div><br></div><div>Just my two Swiss cents,</div><div>l.</div><div> </div><div><br></div><div> </div></div><br clear="all"><br>-- <br><div>Loway - home of QueueMetrics - <a href="http://queuemetrics.com" target="_blank">http://queuemetrics.com</a><br>
</div><div>Test-drive WombatDialer beta @ <a href="http://wombatdialer.com" target="_blank">http://wombatdialer.com</a>
</div><br>
</div>