[asterisk-app-dev] Rename ChannelUserevent to Userevent in ARI?

Dan Jenkins dan.jenkins88 at gmail.com
Sat Apr 19 06:29:17 CDT 2014


On Fri, Apr 18, 2014 at 12:03 PM, Matthew Jordan <mjordan at digium.com> wrote:

> On Fri, Apr 18, 2014 at 11:15 AM, Paul Belanger
> <paul.belanger at polybeacon.com> wrote:
> > On Fri, Apr 18, 2014 at 12:11 PM, Scott Griepentrog
> > <sgriepentrog at digium.com> wrote:
> >>
> >> While working on https://issues.asterisk.org/jira/browse/ASTERISK-22697which adds the ability to raise an arbitrary user defined event message
> from ARI, I have run into a question of backwards compatibility on the
> naming of the event.
> >>
> >> The existing Dialplan Userevent() application is always associated with
> the channel the dialplan is executing on - thus it signals to AMI Event:
> ChannelUserevent and provides details on the channel, along with the
> arbitrary event name specified, and any additional name/value arguments.
>  It also signals the same ChannelUserevent to ARI with the same information.
> >>
> >> When raising a user event through ARI, the URL
> /applications/{applicationName}/user/{eventName} will be used, and
> additional name/value arguments can be specified, along with any number of
> channel, bridge, or endpoints identifiers.  This will be signalled to the
> stasis app, which will be received by that app and any others subscribed to
> it.  If at least one channel is given, the AMI Event ChannelUserevent will
> also be signalled, so as to be compatible with the existing AMI event.
> >>
> >> The question I have then is this: Because the User event is being
> expanded in ARI to allow for signalling without an associated channel, it's
> no longer appropriate to call it "ChannelUserevent".  I think it should be
> renamed "UserEvent", although only within ARI (AMI still uses
> ChannelUserevent, and wont be raised without a channel).  A dialplan
> UserEvent() will still raise AMI ChannelUserevent and also ARI Userevent
> both with a single channel.
> >>
> >> Any thoughts on this?
> >>
> >> Is there anyone using ChannelUserevent in ARI that would be affected by
> this?
> >>
> >> Is it a potential source of confusion to have two different names in
> two API's for the same event?
> >>
> > Don't see an issue renaming it, but how about just user (or custom).
> > Calling an event UserEvent seems redundant to me.
>
> It's a backwards incompatible change. I'd prefer if we don't rename it.
>


Matt, which are you saying no to? The whole thing or Paul's suggestion? I
do agree with Paul - it's a custom event but I can see why you wouldn't
want to go that far. However I can agree with the rename of
ChannelUserevent to Userevent (I don't like how it's Userevent - it should
be UserEvent....but null point) - if you're saying this is a backwards
incompatible change - it is. However, 12 isn't an LTS and there were
discussions about how 12 would be an iterative process due to how many
changes were included in it - this meant there could be these types of
changes included in the process.

The ARI hasn't been in previous versions of Asterisk, and so you'd just be
incompatible with previous versions of 12, of which there aren't that many
- and people should know that if you're using 12, expect changes and
updates.

I don't see an issue with this rename. I'd like to see it go further, I
agree with Paul - call it what it is, it's a custom event. I'd like to be
able to go even further and just name the event myself but that's not going
to happen ;)

Dan



>
> --
> 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
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140419/33da0ace/attachment.html>


More information about the asterisk-app-dev mailing list