Changes between Version 5 and Version 6 of AnnouncerPlugin


Ignore:
Timestamp:
Jan 8, 2008 8:55:52 AM (7 years ago)
Author:
ixokai
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AnnouncerPlugin

    v5 v6  
    2222 * 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. 
    2323 * 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.  
     24 * Distributors: 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  * Resolvers: The purpose of a resolver is to turn a username into an address. For certain corporate sites, a component to simply append "@example.com" to the authenticated trac username will be sufficient. The default resolver will simply use whatever email address the authenticated person has set in trac. Others may be more complicated and query an external resource to determine where to send "fubarbaz"'s emails. 
    2526 * 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.  
    2627