[asterisk-dev] [Code Review] 3494: ARI: Add the ability to raise an arbitrary User Event from the Applications resource

[Scott Griepentrog]

> On May 1, 2014, 4:59 p.m., Samuel Galarneau wrote:
> > /branches/12/rest-api/api-docs/applications.json, line 51
> > <https://reviewboard.asterisk.org/r/3494/diff/1/?file=58118#file58118line51>
> >
> >     What was the thought process behind adding this API endpoint to the applications resource? Would it not make more sense to generate custom user events from the events resource?

The idea is that a user event has to be signaled against/for an application, rather than a specific object, as there may be nothing more than the event name itself.  It could be relocated to the events resource, which is initially where I was planning on putting it, except that it would still have a requirement of specifying an application name.  Only that application (or another application that is listening to another application's messages) will receive the event. 


> On May 1, 2014, 4:59 p.m., Samuel Galarneau wrote:
> > /branches/12/rest-api/api-docs/applications.json, line 89
> > <https://reviewboard.asterisk.org/r/3494/diff/1/?file=58118#file58118line89>
> >
> >     Does this support passing in json to be returned through a web socket event or does the consumer of the web socket event have to parse the string properly?

At the moment it's expecting only name: value, ... -- because I was duplicating the exact function of the dialplan Userevent() app.

I will leave this issue open to remind me to add detection for a json string as well, that's a good point.


- Scott


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3494/#review11809
-----------------------------------------------------------


On April 29, 2014, 11:15 a.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3494/
> -----------------------------------------------------------
> 
> (Updated April 29, 2014, 11:15 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22697
>     https://issues.asterisk.org/jira/browse/ASTERISK-22697
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This changes the implementation of UserEvent stasis messaging and adds additional features:
> 
> 1) Existing channel_user_event stasis messaging replaced with new multi_object_blob in stasis_user.c
> 2) Multi object blob provides ability to signal blob + any number of channel, bridge, or endpoint snapshots
> 3) Changed existing Userevent() app to use new multi object blob - but still publishes to channel
> 4) Added ARI implementation of userevent as /ari/applications/{applicationName}/user/{eventName}
> 5) ARI generated userevent messages are published to application, and also to AMI if channel present
> 
> 
> Diffs
> -----
> 
>   /branches/12/rest-api/api-docs/events.json 413115 
>   /branches/12/rest-api/api-docs/applications.json 413115 
>   /branches/12/res/stasis/app.c 413115 
>   /branches/12/res/res_stasis.c 413115 
>   /branches/12/res/res_ari_applications.c 413115 
>   /branches/12/res/ari/resource_applications.c 413115 
>   /branches/12/res/ari/resource_applications.h 413115 
>   /branches/12/res/ari/ari_model_validators.c 413115 
>   /branches/12/res/ari/ari_model_validators.h 413115 
>   /branches/12/main/stasis_user.c PRE-CREATION 
>   /branches/12/main/stasis_channels.c 413115 
>   /branches/12/main/manager_channels.c 413115 
>   /branches/12/main/asterisk.c 413115 
>   /branches/12/include/asterisk/stasis_user.h PRE-CREATION 
>   /branches/12/include/asterisk/stasis_channels.h 413115 
>   /branches/12/include/asterisk/stasis_app.h 413115 
>   /branches/12/apps/app_userevent.c 413115 
> 
> Diff: https://reviewboard.asterisk.org/r/3494/diff/
> 
> 
> Testing
> -------
> 
> Tested with valgrind to insure no invalid references.  Some leaks found which have been attributed to other code to be fixed separately.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140501/9ec57a4e/attachment.html>