On Mon, Oct 21, 2013 at 3:23 PM, Michael L. Young <myoung at acsacc.com> wrote:
> ----- Original Message -----
>
> > From: "Daniel Jenkins" <dan.jenkins88 at gmail.com>
> > To: "Asterisk Application Development discussion"
> > <asterisk-app-dev at lists.digium.com>
> > Sent: Monday, October 21, 2013 3:59:58 PM
> > Subject: Re: Event naming conventions
> >
> >
> > > So, I guess the first question is do we want to keep the AMI / ARI
> >
> > > naming of events is _somewhat_ similar? AMI tends to be now,
> >
> > > DTMFBegin and ARI the past, PlaybackStarted.
> >
> > I'm sorry I even mentioned the AMI... I'd much rather keep it past
> > tense...
>
> I too would lean more towards using the past tense. It seems more natural
> to see a message saying that "something has occurred".
>
>
Some thoughts here:
When the event standardization for AMI occurred, we focused on two things:
(1) Making the events contain the same subsets of information
(2) Making the event types follow a "begin"/"end" nomenclature, without
the need for a subtype field or further event field inspection
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.
So what about the relationship between ARI and AMI?
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?
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.
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131022/fc49c0ef/attachment.html>
