Re: Rename ChannelUserevent to Userevent in ARI?

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

 





On Fri, Apr 18, 2014 at 12:03 PM, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
On Fri, Apr 18, 2014 at 11:15 AM, Paul Belanger
<paul.belanger@xxxxxxxxxxxxxx> wrote:
> On Fri, Apr 18, 2014 at 12:11 PM, Scott Griepentrog
> <sgriepentrog@xxxxxxxxxx> wrote:
>>
>> While working on https://issues.asterisk.org/jira/browse/ASTERISK-22697 which 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@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[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