BOINC Notification System

As the number of projects increase it becomes increasingly difficult for volunteers to keep track of any relevant news a project publishes. Volunteers may only check project websites once in a blue moon. A system is needed to keep the volunteers engaged with a project.

When we talk about volunteers in regards to this feature we are actually talking about three different types of volunteers:

• A volunteer who attaches to a project but doesn’t participate in the forums.
• A volunteer who attaches to a project and participates in the forums.
• A volunteer who attaches to a project and becomes involved enough with the project that they begin to help the project with support issues.

The volunteer should be in control of how much information is going to be exposed to them by way of the notification system.

The rest of this document will describe how the notification system will work.

Feed

When a volunteer attaches to a project, one or more notification feeds become available to them. These feeds are published using the ​RSS 2.00 specification.

Example feeds a project may wish to expose are:

• Project news (http://<project_url>/rss_main.php)
• Scientist blogs
• Administrator blogs
• Private Messages
• Forum threads that a volunteer is monitoring
• A whole forum to answer questions or to deal with problems as they arise.

Example:

http://www.example.com/rss_main.php
http://www.example.com/forum_pm_rss.php?auth=4ebd3e5fd8a88f48ed708f04f81fefb7

Parameter table:

Parameter	Default Value	Meaning
auth	<null>	Authenticator of the volunteer requesting the feed data. NOTE: For private feeds no information should be provided without the full authenticator. Weak authenticators should be treated as though no authenticator has been provided.
last_guid	<null>	The last guid received by the client.

Feed List

The feed list is published to the client software as part of the client parse-able project preferences.

When the client software connects to the server scheduler it’ll receive an updated list of feeds the client should download as well as any special properties about the feed (private feed for example).

Example:

<notification_feeds>
    <feed>
        <url>http://www.example.com/rss_main.php</url>
        <name>Project News</name>
        <update>86400</update>
    </feed>
    <feed>
        <url>http://www.example.com/forum_pm_rss.php</url>
        <name>Private Messages</name>
        <update>86400</update>
        <private />
    </feed>
</notification_feeds>

Property table:

Attribute	Default Value	Meaning
url	<null>	The URL to access the feed
name	<null>	Volunteer friendly name for the feed
update	86400	Number of seconds in between updates
private	false	Should the authenticator be provided to the feed
disabled	false	Feed is disabled and the client should not request updates
disabled_date	<null>	Epoch time in which the feed was disabled. A month passed the date and both the server and client software should delete any relevant information about the feed.
application_only	false	Feed is used by an application and should not be shown in BOINC Manager or the BOINC Screen saver.

Server Scheduler

The server scheduler is responsible for aggregating the various pieces of information about feeds and pushes the result to the client as part of the scheduler reply. A similar process is used for the GUI URLs.

General workflow:

• Issue query to determine of the volunteer has customized their feeds.
• Read feeds.xml for feed baseline.
• Merge the results of feeds.xml and the results of the query, with preference given to the volunteer’s selections.

If an empty result set is returned by the database, then pass the contents of feeds.xml unmodified.

Notification Supported Flag

When the scheduler receives the notification flag it should add any user messages to the BOINC client feed by including a channel and a new item for each user message.

Notification flag:

<notifications_supported />

Scheduler Reply

User messages generally contain information the volunteer needs to know such as there isn’t enough disk space allocated to the project to run a task instance, or they weren’t assigned any work because they ran out of quota.

Messages like a project being out of work should not be included in the notification stream.

Where possible, notification messages should contain information on how to correct the problem.

Channel items:

<channel>
    <item>
        <description>I need more disk space</description>
        <pubDate>Mon, 30 Sep 2002 01:56:02 GMT</pubDate>
        <guid>http://www.example.com/1</guid>
    </item>
    <item>
        <description>I need more memory</description>
        <pubDate>Sun, 29 Sep 2002 19:59:01 GMT</pubDate>
        <guid>http://www.example.com/2</guid>
    </item>
</channel>

Property table:

Attribute	Default value	Meaning
description	<null>	An xml encoded message that the volunteer needs to act on
pubDate	<scheduler reply time>	RFC 822 representation of the scheduler reply time
guid	<null>	Unique message ID prefixed with the master URL of the project

Project Website

A project’s website is the main focal point for adding and removing notification feeds.

Each forum and each thread should have a ‘notify me’ button that’ll add an entry to the notification list in the project preferences for the volunteer.

A new entry in the Preferences section of the Your Account area will be created to manage all the feeds a volunteer is currently subscribed too.

This new section should allow the volunteer to change the refresh rate for any feed they want to be notified about. It should also allow them to disable any feed.

Core Client

Client Manager

Screen Saver