Build Service/Concepts/Notification

From openSUSE

Hermes Personal Message Dispatching

Introduction

Purpose

Many already existing systems produce a lot of information for their users. Most of them, especially at SUSE, do that by sending email.

That was a very practical and quick solution in the past, but nowadays there are more elegant methods of information providing and keeping. The purpose of hermes is to give the choice in which way a user wants to be notified about what.

Variety of Delivering Systems

Todays users expect information to come up in different ways like being presented on a web page, coming through news systems or as jabber messages or as XML based RSS feeds.

Aggregation

Moreover users would probably love if messages of the same type get aggregated to a digest message that is posted daily instead of one by one. For example, for failed package builds it would be sufficient to get one message per day that contains a list of all failed packages of the day (possibly without duplicates) instead of tons of messages with similar content.

Choice

User should have the choice how, which and in which form messages get delivered. There should be a interface where one can maintain the settings which kinds of messages get delivered how.

For example one might prefer to get PDB- and package build fail messages as nightly digest mail, but wants to receive buildservice messages directly via jabber to the mobile phone.

Architecture

To fulfill the requirements, the following functional blocks are needed:

• The User Preferences Module stores the different choices a user of the system like which kind of messages should be delivered in which way. It feeds it's information in nearly all other blocks

• The Storage represents the interface for incoming messages and stores them into the database or transfers it to the Relay if immediate sending is required.

• A Database holds the messages until their delivery. Since the data is structured a relation database will be ok.

• The Relay is triggered time based and checks if messages are due for delivery. If so it assembles messages if required (like digests) and proceeds them to the agents for delivery.

• The Agents are specialised transport modules that deliver a message using a special technology.

The modules can all run on one machine, even in one container, these are just logical blocks.

Interfaces

Basically there are three interaction points with the system:

• Message Storage through a HTTP REST interface

• User interaction for preference setting through a webapp

• Message delivery through the various agents

Some details about each of them follows.

Message Storage

Applications can store messages into the system via a REST interface. According to a message information block, the message is scheduled, digested or sent immediately.

A message is stored through a POST request to a special url that is of the following form:

http://hermes.opensuse.org/<messagetype>

having messagetype as the Message Type of the message. The message is defined by a Message Description in XML described below.

Updating already posted messages is not planed.

Message Query

To query already existing messages from the Hermes Storage a GET request to the following url returns the stored messages.

http://hermes.opensuse.org/<username>/[<messagetype>]

Note that <messagetype> can be ommitted.

Message Information Block

Following is an example of a message information block. It is a XML document that must be sent to the Storage module to post a message.

  <hermes:message xmlns:hermes="http://xml.opensuse.org/hermes" type="example">
     <hermes:sender id="build service">
       The openSUSE build service
     </hermes:sender>
     <hermes:recipients>
       <hermes:to id="freitag">
         <hermes:reason>optional: why does the user gets the message</hermes:reason>
       </hermes:to>
       <hermes:cc id="ro"/>
     </hermes:recipients>

     <hermes:tag name="severity" value="normal"/>
     <hermes:tag name="priority" value="4"/>

     <hermes:body>
We want to inform you that this is something we like...
     </hermes:body>
  </hermes:message>

Sender Information

The sender information is stored in the sender tag. It is not taken from the login information of the message poster because that would require that every poster has an account. We learned that this is not always the case and makes things more complicated. If spam problems come up login for message storage can be set up.

Recipients

The recipients list is a list of to- and cc recipients. These recipients can be ommitted in case there is only one to recipient that is specified in the URL the message is posted to. See above for explanation.

The recipients are identified through their system identy, e.g. an LDAP entry or a Novell iChain account.

Tags

The messages contain tags that will be used to sort and group message for agents that support that. Tags can be used agent specific to enable features typically to the agent. A example for this is that the message tags can be set as header values for the mail agent.

Message Type

The message type is special element to qualify the kind of a message. It is part of the url where messages are stored to or queried from and helps in structuring. Basically the message type is a string that is completely freely chooseable from the posting system. The poster does not have to care about if the message type exists or was used before. If a message type is not know to hermes, the message time schedule and delivery is handled in a user setable default.

Every ever [<- think again] used message type shows up in the users list of active message types. The user than can

- see and edit what kind of messages she/he received

- set a special treatment for the message type in terms of time scheduling and delivery.

In later releases of Hermes it might give submessage types that inherit the settings of their parents.

Agents

There can be different agents that deliver the messages according to the time constraints defined for the message type. The kind of delivery (by mail, as Jabber message etc.) is also subject of configuration done through the User Preferences Module. The Agents get triggered by the Relay to do message delivery.

A mail agent as well as a RSS Agent should be implemented first, beside the web message broker.

The interface between Relay and the Agents is TBD, probably another REST interface is sufficient.

The Hermes Webapp

The Hermes Webapplication fulfills two purposes: Setting user preferences and show lists of messages. Since the list functionality is an agent, it could be implemented independently as well.

User Preferences

This module lets the user edit his/her personal settings. Basically that is: How is a message of a distinct type to be delivered and under which time constraint?

Additionally the Preferences module lets the user edit things like the default delivery. Future extensions could be a vacation rule like which messages are to keep and which could be dropped etc.

Message Lists

The Hermes Web app shows lists of messages in a sortable, filterable and smooth way. The rest is up to the fantasy of the implementer and the users demands :-)