!rst

Pre-planning

Would a notification server add value to our architecture?
Does it simplify our other apps?
Would integrating it into our apps be intrusive or easy?
How to balance generality with specifics of our environment?

Use case

User makes several changes in packagedb interface
Packagedb makes change and constructs event messages of [who did it, type of event, message]
Packagedb adds event messages to a queue messages are sent to the notification server
Notification server receives message. Saves to its queue. Sends acknowledgement.
Packagedb receives ack and removes message from queue.
After timeout, notification server processes queue, constructing messages, saving logs, and updating RSS feeds.
}}}

toshio commented 15 years ago

Talked to lmacken the other day and we think we might be able to do this using moksha's infrastructure. We'd pass messages using AMQP and moksha would take care of disbursing the information via email, RSS, etc.

toshio commented 15 years ago

to see if we could handle that information as well. We'd need to be careful about security to do that, though.

lmacken commented 15 years ago

I think that setting up a Qpid AMQP broker would be a great start. From there, we can easily start sending various infrastructure events to it. Then, hooking up Moksha to it is going to be trivial, and will allow us to easily write "consumers" of these messages that can do interesting things, such as send email notifications, perform various jobs, etc.

toshio commented 14 years ago

Seems like qpidd setup is the first step in this.

mmcgrath commented 14 years ago

This is actually 'up'ish now. The big part was me training myself on how it works. If we have test messages let me know because I can set it all up in staging fairly quickly.