<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 21, 2013 at 3:23 PM, Michael L. Young <span dir="ltr"><<a href="mailto:myoung@acsacc.com" target="_blank">myoung@acsacc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
<br>
> From: "Daniel Jenkins" <<a href="mailto:dan.jenkins88@gmail.com">dan.jenkins88@gmail.com</a>><br>
> To: "Asterisk Application Development discussion"<br>
> <<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a>><br>
> Sent: Monday, October 21, 2013 3:59:58 PM<br>
> Subject: Re: [asterisk-app-dev] Event naming conventions<br>
<div class="im">><br>
><br>
> > So, I guess the first question is do we want to keep the AMI / ARI<br>
><br>
> > naming of events is _somewhat_ similar? AMI tends to be now,<br>
><br>
> > DTMFBegin and ARI the past, PlaybackStarted.<br>
><br>
> I'm sorry I even mentioned the AMI... I'd much rather keep it past<br>
> tense...<br>
<br>
</div>I too would lean more towards using the past tense.  It seems more natural to see a message saying that "something has occurred".<br>
<br></blockquote><div><br></div><div style>Some thoughts here:</div><div style><br></div><div style>When the event standardization for AMI occurred, we focused on two things:</div><div style>    (1) Making the events contain the same subsets of information</div>
<div style>    (2) Making the event types follow a "begin"/"end" nomenclature, without the need for a subtype field or further event field inspection</div><div style><br></div><div style>Beyond that, there wasn't much thought given to whether or not event pairing should be "Started/Finished"; "Begin/End", "Created/Destroyed", etc. Maybe we should have been concerned about it, but our focus was more on the previous two points and not on whether or not Started is better than Begin.</div>
<div style><br></div><div style>So what about the relationship between ARI and AMI?</div><div style><br></div><div style>AMI is not ARI :-)  There's no explicit guarantee in either interface that the events are the same or that events happen at the same time. That's on purpose: keeping the interfaces loosely coupled insulates them from each other, and let's them be more flexible. If we need to expose information in AMI that should be hidden in ARI, we don't have a set of rules that require us to show that information to the detriment of ARI. The converse is true as well: ARI is likely to receive a large number of enhancements over the next year - do we want changes in ARI to have a ripple effect in AMI? In other words: do we really want ARI to dependent on a scheme in AMI?</div>
<div style><br></div><div style>I'd prefer to keep the two interfaces distinct. The underlying architecture in Asterisk 12 already enforces a consistent scheme of channel/bridge lifetime, such that interactions between the two interfaces are predictable. Anything else beyond that feels more cumbersome and pedantic than it is worth.</div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>