[asterisk-dev] Dynamic server side event type filtering in ARI

[Kevin Harwell]

On Thu, Dec 20, 2018 at 12:20 PM sduthil at wazo.io <sduthil at wazo.io> wrote:

> Could you give a use case for the filtering? I can imagine one, but not
> sure it is really useful:
>
> Use case: an application subscribes to all channels, in order to give a
> real-time view on all calls currently talking on the server. This
> application is only interested in ChannelCreated, ChannelUpdated,
> ChannelCallerID and ChannelDestroyed. The events like ChannelVarSet or
> ChannelTalkingStarted are just noise wasting CPU time of the application.
>

Something like this is basically what we had in mind. For now we're just
going to focus on filtering the event types, but in the future, if deemed
useful, we might eventually add filtering on event type details as well.


> IMO, I would prefer a whitelist approach:
>
> - In future versions, Asterisk will inevitably add new events. Those new
> events may be quite frequent too. The point of the filter is to decrease
> the application's event flow, and if the filter is not updated to
> account for the new events, then the application's event flow may grow
> back. This may have a performance impact on the application side. I
> would prefer any Asterisk upgrade to have a minimal potential negative
> impact on performance.
> - A specific version of an application is interested only in a subset of
> events. It knows what events it is interested in, and is able
> to give a list of such events. IMO, the application should not have to
> know about events it is not interested in, and should even less have to
> maintain a list of all events it does not want.
>

I think you make a good case for having a whitelist. Unless it is a super
large headache I will probably go this route now.


>
> Here is another API proposition. Note: I have done no analysis of what
> is easier to implement within Asterisk. I'm just stating what I would
> like to have for the REST interface, as an application developer:
>
> I propose to have one event filter per application, and consider the
> event filter as a resource that is always present (no POST, no DELETE),
> that would by default have no restrictions on events. The filter
> resource would look like this:
>
> GET /applications/{applicationName}/eventFilter
>
> {
>   "allow": [
>     {"type": "StasisStart"},
>     {"type": "ChannelUserevent",
>      "eventname": "eventname"}
>   ],
>   "disallow": null
> }
>
> 1. The whitelist and the blacklist can be implemented. The first version
> may only support the "blacklist" keyword, if it is easier to implement.
> 2. Filtering could apply on other fields than the event's "type". The
> first version of the event filter may be implemented by only supporting
> the event's "type" field.
>
> So, as a first step, an equivalent to Kevin's proposition would be:
>
> GET /applications/{applicationName}/eventFilter
>
> {
>   "disallow": [
>     {"type": "eventType"},
>     {"type": "eventType"},
>     ...
>   ]
> }
>
> Modification of the filter would be done with a PUT:
>
> PUT /applications/{applicationName}/eventFilter
>
> {
>   "allow": [
>     {"type": "StasisStart"},
>     {"type": "StasisEnd"},
>   ],
>   "disallow": null
> }
>
> When the application is created, the event filter is empty and looks
> like this:
>
> GET /applications/{applicationName}/eventFilter
>
> {
>   "allow": null,
>   "disallow": null
> }
>
> allow = null means "no filtering".
> allow = [] means "no events allowed", if we keep a strict meaning of the
> array as "any event that match at least one filtering directive is
> sent". It could also mean "no filtering", since "no events allowed" is
> not very useful...


Joshua Colp also proposed something like this. After seeing it laid out I
think I lean toward this approach or something very similar to it. Moving
forward, at the very least, we want a flexible way to increase future
filtering functionality with little, or preferably no change to the API.
Pushing the allow/disallow specification down into the body allows that to
happen.


>
>
What happens when "allow" and "disallow" are used together and match the
> same event? I propose that "disallow" takes precedence.
>

Yes one would have to take precedence over the other, or make it so the
whole operation is rejected and an error is returned.


> A PATCH operation could also be implemented to add or remove filter
> directives without having to PUT everything.
>
> Do you think a "reset" operation would be interesting? Something to
> remove all filters? Perhaps a DELETE? But that would be twisting the
> semantics of the DELETE, since the eventFilter resource would still be
> there. A POST on /applications/.../eventFilter/reset ? Or a POST with
> {"allow": null, "disallow": null} ?


It's probably worthwhile to have some kind of reset or way to clear the
filtering. I'm thinking that "no eventFilter" means the application would
get all events, so I think a DELETE would work here. By having "no
eventFilter" equal "all events" we can maintain the way things currently
work (meaning current applications would not have to change). We can also
always add this functionality in a subsequent patch too if app developers
decide it's needed.


>
>
-- 
> Sébastien Duthil
>
> ---
>

Many thanks for the detailed feedback!

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181227/0ed2c2be/attachment.html>