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

[sduthil at wazo.io]

On 2018-12-13 4:27 p.m., Kevin Harwell wrote:
> I'm looking into adding the ability for an ARI application to
> dynamically control which event types it would like sent to it[1]
> (i.e. server side event type filtering). I'm currently leaning
> toward implementing this as a blacklist. I believe doing so would
> ease the development burden on the Asterisk side as well as on the
> application side of things while maintaining current application
> received event type expectations.

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.

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.


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...

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

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} ?

-- 
Sébastien Duthil