> 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?
>
> Scott Griepentrog wrote:
> 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.
>
> Samuel Galarneau wrote:
> There are other calls in ARI where an application name can be passed
> (originate on channel for example). That shouldn't force the method to be put
> under the applications resource however.
>
> Since the end goal of calling this method is to raise a user event, it
> seems having the method under the events resource would make more sense.
I've changed the URI to /events/user/{name}.
- Scott
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3494/#review11809
-----------------------------------------------------------
On May 9, 2014, 5:29 p.m., Scott Griepentrog wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3494/
> -----------------------------------------------------------
>
> (Updated May 9, 2014, 5:29 p.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/res/stasis/app.c 413115
> /branches/12/res/res_stasis.c 413115
> /branches/12/res/res_ari_events.c 413115
> /branches/12/res/ari/resource_events.c 413115
> /branches/12/res/ari/resource_events.h 413115
> /branches/12/res/ari/ari_model_validators.c 413115
> /branches/12/res/ari/ari_model_validators.h 413115
> /branches/12/main/stasis_endpoints.c 413115
> /branches/12/main/stasis_channels.c 413115
> /branches/12/main/stasis.c 413115
> /branches/12/main/manager_channels.c 413115
> /branches/12/include/asterisk/stasis_channels.h 413115
> /branches/12/include/asterisk/stasis_app.h 413115
> /branches/12/include/asterisk/stasis.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
>
>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
