Archive:Hermes Architecture

This article is being considered for deletion! Reason: openSUSE is not using Hermes anymore, development has stopped in 2013.. Please do not blank, merge, or move this article, or remove this notice. Refer to this article's discussion page and our deletion policy for more information.

Hermes

Hermes - Architecture - Subsystems - Contribute - Webui - Administration - OBS Integration

Architecture

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

• The User Preferences Module stores the different choices of which notifications a user would like to receive how. With this part of the system, the user controls how the messages approach her. 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 is used.

• 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 specialized transport modules that deliver a message using a different technologies.

These are the logical building blocks. For more details read about Hermes' subsystems.

---

Interfaces

Basically there are four interaction points with the system:

• Message Storage through a HTTP CGI (later REST) interface
• User interaction for preference setting and message reading through a rails based web application
• An admin web interface for administration tasks
• Message delivery through the various agents

Some details about each of them follow.

Message storage

Other applications which want to feed their notifications into Hermes can store notifications into the system via a HTTP based CGI interface

Concept: Hermes REST Interface

The REST interface is not yet implemented but here's the concept.

Clients can post notifications to Hermes sending a POST request to

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

All parameters are added to the POST request.

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

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

Notification type

The notification type is a special element used to qualify the kind of notification. It need to be one parameter of the CGI POST request. Basically the message type is a string freely choseable from the posting client. The poster does not have to worry about whether the notification type exists or was used before. If a notification type is not known to Hermes, the notification time schedule and the delivery type is handled by a user configurable default.

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

---

Agents

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

---

The User Web Application Starship

The Hermes web application called Starship fulfills two purposes: Managing user preferences and showing lists of messages. For the openSUSE Hermes installation Starship is hosted at http://hermes.opensuse.org.

This module lets the user edit his/her personal settings. Basically that is how a message of a distinct type is to be delivered and under which time constraint. Furthermore, filters which narrow down the message delivery even more can be configured.

See user documentation for Starship: Hermes usage documentation

Starship also shows lists of messages in a sortable, filterable and smooth way.