Middlewares works in between the master channel and slave channels, they look through messages and statuses delivered between channels, passing them on, make changes or discarding them, one after another.

Like channels, middlewares will also each have an instance per EFB session, managed by the coordinator. However, they don’t have centrally polling threads, which means if a middleware wants to have a polling thread or something similar running in the background, it has to stop the thread using Python’s atexit or otherwise.

Message and Status Processing

Each middleware by default has 2 methods, process_message() which processes message objects, and process_status() which processes status objects. If they are not overridden, they will not touch on the object and pass it on as is.

To modify an object, just override the relative method and make changes to it. To discard an object, simply return None. When an object is discarded, it will not be passed further to other middlewares or channels, which means a middleware or a channel will never receive a None message or status.

Other Usages

Having rather few limitation compare to channels, middlewares are rather easy to write, which allows it to do more than just intercept messages and statuses.

Some ideas:

  • Periodic broadcast to master / slave channels

  • Integration with chat bots

  • Automated operations on vendor-specific commands / additional features

  • Share user session from slave channel with other programs

  • etc…

Implementation details

See Middleware.