On Wed, Feb 26, 2020 at 02:45:24PM +0000, Jeremy Cline wrote:
FYI before I left the team I started hacking up a replacement[0]. My
design focused on how to get as rich a feature set as I could using
only AMQPs currently available filtering features. There's a couple
feature differences for end-users:
* Users can filter on message importance based on
fedora_messaging_severity and any documented optional header[1].
Users can also provide AMQP-formatted topics they'd like to receive
notifications for (again, with a severity filter). There's no running
arbitrary regex over messages to filter.
That may be enough. I guess we will need to look at the use cases here
and see if there's other ones that need some kind of regex...
* Batch delivery is only available at fixed intervals, unlike the
current system which takes how many pending messages there are as
well.
This puts all the responsibility of filtering the messages for each
user on RabbitMQ (which is very good at filtering messages and keeping
them until a user wants them). Each user gets a message queue in the
broker, and all the notification service needs to do is make sure the
bindings are set up to filter messages into the queue and dequeue +
deliver the message. The prototype is using Twisted for that.
I like a lot about this plan. ;)
kevin