Event naming conventions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 21, 2013 at 6:15 AM, Paul Belanger <paul.belanger at polybeacon.com
> wrote:

> So I am starting to work with ARI events and notice our naming
> conventions are not consistent.  I wanted to have a discussion about
> maybe coming up with an ideal suffix and stick with it.
>
> For example, we have
>
> StasisStart
> StasisEnd
>
> PlaybackStarted
> PlaybackFinished
>
> BridgeCreated
> ChannelStateChange
>
> As you can see, we are no consistent, the majority of the events end
> with 'ed', which is fine it indicates past tense.  So, we we want to
> continue with that theme, then all events should be referred to as
> past tense.
>
> Additionally, Stasis and Playback events have 2 different toggles
> (StasisEnd and PlaybackFinished) again, I don't see a need for 2
> different end conventions. Something like:
>
> Started / Stopped
>
> is better with 'ed'. But finished works well too.
>
> Thoughts?
>
> --
> Paul Belanger | PolyBeacon, Inc.
> Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
> Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
>
>

On that note though, should we make this consistent with the AMI? Or is
there even any connection at all?

https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification

I know that the DTMF event changed to DTMFBegin and DTMFEnd.... and the
same for Dial... So these aren't past tense...but then I know there are AMI
events which are past tense i think...

I like the idea of past tense consistency but is there anything we can
learn/take from AMI to make "Asterisk" consistent with itself?

But +1 in general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131021/1dc87233/attachment.html>


[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux