Other URLs

• NotificationSystem
• Use Cases

Description

• Iteration 1
  • Principle
  • Storage
• Iteration 2
• Iteration 3
  • Limits

Iteration 1

Principle

An application send a message to the Notification Manager. According to the type of the notification and the preferences of the users, the Notification Manager sends emails to users and create "web notifications": ie the notifications that you can see directly in the wiki.

The Notification Manager should probably work asynchronously because it can take time to send emails or generate the number of needed web notifications.

Storage

The Notification and NotificationUser (ie. the "WebNotification" defined previously") should probably been implemented in the Database directly, because otherwise it could create tons of wiki documents, with history and etc... and could slow down the wiki.

NotificationType and NotificationPreference could be implemented as standard XObjects.

A Notification could contain standard rendering syntaxes, and also velocity macros so that it is possible to display complex things such as buttons, links, etc...

Iteration 2

• NotificationType should not be a wiki page, because a component should be able to create it.
• The entries of NotificationUsers could be created lazily: when the user reach the page, the system look at the notification she might fit, and create the entry on the fly.
  • Benefit: entries are not created for spam users or users who never connect.
  • Drawback: more CPU usage at each request
• A notification should have a target field: for example some notif concern only a user or a specific group.

Possible alternative: not store the "read" status on the server, but on the local storage of the browser (not very reliable).

Iteration 3

After a discussion with Vincent Massol, we have realized that we should not create a new store, but instead use the Activity Stream store (which is more or less the same thing).

But we need to add 3 thing to the AS store:

• Make AS logs every loggable events (not only events it knows) in a generic way
  • Since Events are typed we need to be able to convert an Event to a ASEvent. Add a system to be able to plug a component if some type of events needs a special handler. 
  • We need to log only some events. For example ActionExecutedEvent shouldn't be logged. Nor ApplicationStartedEvent. To do this introduce some LoggableEvent or NotificationEvent interface and only log those.
• Add a "audience" parameter (users/groups concerned by the event) to each logged event (via a new table).
• Add a table to store what are the entries read by each user (the status table).
• Register in each user's profile what events the user wants to receive

So we forget the Notification Manager. Instead, an extension should send an event through the Observation Manager. This event should specify the audience too when they want to restrict the audience. If no audience is specified then the event is addressed to everyone.

Then, on the notification side, we look at the AS entries:

• for each entry, look the type
• look-up a "displayer" for the type of event
• display the event with that displayer

A displayer will be a component. Like Wiki Macros, a displayer should also be created with an XObject (XWiki.Notifications.Code.NotificationDisplayerClass).

Limits

If an application written in velocity needs to send a custom event (like TopicCreatedEvent for the Forum Application), it needs to define this event in a JAVA module. In the future, we could imagine a script service that read a JSON string to create a custom event.