Notifications/Technical Architecture
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Entities
[edit]- Event
- Echo revolves around events. An Event is something that occurs that may result in one or more notifications. For example, "User X edited the talk page for user Y", "User X edited User talk:Y" and "User X reverted user Z's edit" are all events. They may in fact refer to the same underlying action, but for the purposes of Echo they are considered separate events. The most important attribute of an Event is its "type", which determines its handling within Echo.
- Action
- An Action is something that is triggered when an Event occurs. A Subscription rule will determine which Actions are fired.
- Notification
- A Notification associates a Consumer with an Event. Echo dispatches Notifications when an event occurs that causes the 'notify' Action to be taken for a particular Consumer. Notifications are transient, and stored for a fixed period of time. They can be retrieved via the API or via the Web Interface.
- Subscription
- A Subscription is a statement that a particular Consumer is interested in a particular class of events. A subscription specifies an event type and optionally a page. Any event with that type (and on that page, if a page is specified) will result in a determined set of actions occurring. These actions may be explicitly specified or implicit for that type of event.
- Subscriptions may be explicit or implicit. Echo maintains a list of explicit (Consumer X wants to be notified and emailed when event Y occurs on page Z) and implicit (All Consumers should be notified and emailed when the event 'edit-talk-page' occurs on their talk page) Subscription rules. Implicit rules can be overridden by explicit rules.
- Consumer
- A Consumer is somebody who cares about Events. Currently the only type of Consumer is a MediaWiki user account.
Moving Parts
[edit]Echo Core
[edit]Echo Core is the Echo system proper. It accepts Events from publishers, maintains explicit and implicit Subscription rules, and materialises events. An Event is materialised by resolving the Subscription rules that apply to it and firing the Actions stipulated by those rules. Materialisation will not always happen immediately â the time when Events are materialised is determined by the Queueing System.
Event Publishers
[edit]An Event Publisher is a part of MediaWiki that creates Events and submits them to Echo. Once an Event has been submitted to Echo, the obligation of the Publisher has ended.
Publishers will often also add their own implicit Subscription rules and Notification Formatters.
Notification Formatters
[edit]A Notification Formatter accepts a configuration (which is typically set on a per-event-type basis), and a Notification (with its corresponding Consumer and Event) and spits out a representation of the Notification. It may support a number of output formats, including HTML, Text and Email (subject and body).
Queueing System
[edit]The queueing system determines when Events are materialised. This will depend on the required latency (higher for email, lower for notifications to infrequent visitors), the publish rate of the Publisher, the number and consumption characteristics of the consumers, and other undetermined factors.
Currently all events are materialised in order from the Job Queue.
User Notification Preferences
[edit]With a potentially limitless number of clients, it is not feasible for users to be expected to adjust their preferences on a per-wiki basis. As such, each wiki will have a notification preferences page that reads in a list of all Publishers and the Event types from the Central Service.
The user can then indicate which Events they wish to be notified about and which back-ends they wish to receive the notifications on. These preferences are then stored on the Central Service, not the local wiki.