| | 15 | === Design === |
| | 16 | Users won't be interested in this; but developers might-- skip if you just want to use the plugin :) |
| | 17 | |
| | 18 | Announcer is not meant to just scratch a particular itch of wanting to hear about a certain kind of thing, or have a message be sent in a certain format. It's meant to be a comprehensive and extensible notification architecture that will allow far greater control of notification delivery to users, and also make it very easy for developers (me, you, anyone!) to modify how it works. |
| | 19 | |
| | 20 | Announcer is itself a plug-in, but it will be able to be enhanced by other plug-ins should anyone want to. As such it has a number of places where its existing behavior can be added to: |
| | 21 | * Producers: These initiate an event; the core Announcer producers are almost all implementations of I*ChangeListener interfaces, such as ITicketChangeListener, IAttachmentChangeListener, and IWikiChangeListener. When they receive events across these various interfaces, they package them into an event and (in particular) classify each event as a "realm" and "category". For example, "ticket, created", "ticket, changed", "ticket, deleted", "ticket, attachment added", etc. |
| | 22 | * Subscribers: These are responsible for discovering who is interested about hearing an event. Every subscriber registers itself as willing to handle subscriptions for a particular realm and/or category, and from there it checks to see what users may be interested in an event. The subscriber returns the user who is interested about the event and what method they're interested in hearing about it via-- e.g., email, IRC, IM, or whatever. |
| | 23 | * Formatters: Once it has been decided that this particular user is interested in hearing about this event, a formatter is invoked to transform that event into an actual message. Plain text, HTML, oneliner, are all example formatters. If someone would like the ticket change email to always display certain key properties even if not changed, all that's needed is a new formatter to accomplish that. |
| | 24 | * Distributor: Finally, the Distributor is the component that actually -sends- the message. Each one generally transmits via one type of communication channel; email, IRC, AIM, and suchlike. |
| | 25 | * Preferences: Various components may change their behavior based on user-preferences; does the user prefer HTML or plain-text? does the user not want to get messages when they update tickets? Etc. As each of these components is optional, and others may add new ones at a whim, how to manage the preferences was something of a problem. Each component could add its own preference panel, but that would litter up the interface a lot. Instead, Announcer provides its own preference interface that behaves the same way as IPreferencePanelProvider, except instead of providing an entire panel, it provides only a single "box". All the boxes are rendered together. |
| | 26 | |
