Гермес

Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу)

Вступление

Назначение

Многие существующие системы генерируют большое количество информации для своих пользователей. Большинство из таких систем, особенно в SUSE, передают информацию по каналам электронной почты.

Данных подход представлял собой в прошлом очень практичное и быстрое решение, но в настоящее время есть более изящные методы информационного сопровождения. 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.

Собирание

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.

Выбор

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.

Архитектура

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.

Интерфейсы

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.

Хранилище сообщений

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 planned.

Запрос сообщений

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 get 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 messages for agents that support that. Tags can be used (agent specific) to enable features typical to the agent. An example for this is that the message tags can be set as header values for the mail agent.

Типы сообщений

The message type is a special element used to qualify the kind of 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 (and freely) chooseable from the posting system. The poster does not have to worry about whether the message type exists or was used before. If a message type is not known to hermes, the message time schedule and delivery is handled by a user setable default.

Every used message type shows up in the user's list of active message types. The user can then

- 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.

Агенты

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 to configuration done through the User Preferences Module. The Agents get triggered by the Relay to do message delivery.

A mail agent as well as an 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.

Гермес Webapp

Гермес WebApplication выполняет две цели: Настройка пользовательских предпочтений и показывающие списки сообщений. Так как список функциональности агента, он может быть реализован как самостоятельно, так. Для OpenSUSE услуги, веб-приложение Гермес называется "Звездный" можно ознакомиться на http://hermes.opensuse.org.

Где находится информация о том, как ввести RSS-каналы не предусмотренных в OpenSuse?

Настройки пользователя

Этот модуль позволяет пользователю редактировать свои персональные настройки. В основном это является сообщением различного типа, который будет поставляться и в соответствии с которым время ограничевается?

Кроме того Настройки модуля позволяет пользователю редактировать такие вещи, как доставки по умолчанию. Будущее развитие может быть отпуск, как правило, какие сообщения оставить, а какие могут быть удалены и т.д.

Списки сообщений

Web-приложение Hermes показывает списки сообщений в отсортированном и отфильтрованном виде. Остальное зависит только от фантазии разработчика и требований пользователей :-)