wiki:Notifications

Version 61 (modified by romw, 14 years ago) (diff)

Include the BOINC Project name within the item

TOC?

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.

Notifications Supported

Clients that support the BOINC Notification System should include the following flag in the scheduler request:

<notifications_supported />

When the BOINC Server scheduler sees this flag it’ll include extra information in the scheduler reply that is to be included in the BOINC Server Action Feed, defined later, and a list of feeds the client should be monitoring.

Feeds

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 Notifications
  • Scientist blogs
  • Administrator blogs

Request

Example:

http://www.example.com/notify_rss.php
http://www.example.com/notify_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.

Response

Example:

<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 ({1})</description>
        <pubDate>Sun, 29 Sep 2002 19:59:01 GMT</pubDate>
        <guid>http://www.example.com/2</guid>
        <boinc_param_1>64</boinc_param_1>
    </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
boinc_project The volunteer friendly name for the project
boinc_param_1 ... boinc_param_x <null> Optional parameter(s) for the item description

NOTE: While on face value the inclusion of the GUID to the client software might seem overkill, it serves two important purposes.

  • It can be used to prevent duplication messages from the same project from appearing in the user interface across multiple scheduler requests.
  • Provides a mechanism to display localizable server messages within the user interface.

Localization

Items being passed to the manager by way of the server scheduler or core client will now be identified by a item identifier. The item identifier will be appended to the of the project's master url and we used as the item's GUID.

Item identifier rules:

  • Item identifiers start at 1.
  • Item identifiers should not be removed from the item list and cannot be removed if no longer used.
  • Items should be enclosed in the _("Test Message") macro syntax.
  • Item parameters are enclosed in ‘{}’ braces with an index to the position in which the parameter should replace the marker.

When new items are added poEdit or some other string extraction tool should be used to update the BOINC-Server-Messages.pot template file. After the localization process has been completed the resulting BOINC-Server-Messages.mo file should be shipped with the client software.

A string in need of localization would look like this:

_("This client needs {1} of additional memory. {2} detected in total.")

After translation it could look like this:

_("Your computer has {2} of total detected memory, but the client needs an additional {1} in order to be assigned work.")

The client software should replace the positional markers with the optional parameter values specified for the message.

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 (application only for example).

Example:

<notification_feeds>
    <feed>
        <url>http://www.example.com/notify_rss.php</url>
        <name>Project Notifications</name>
        <update>86400</update>
    </feed>
    <feed>
        <url>http://www.example.com/science_blog_rss.php</url>
        <name>Science Blog</name>
        <update>86400</update>
    </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
last_update 0 The epoch time of the last successful update
application_only false Feed is used by the project application and should not be shown in BOINC Manager or the BOINC Screen saver. The contents of the feed should be written to the init_data.xml file in the slot directory before the application is launched.

Initial Feeds

BOINC has several built-in community defining features and feedback mechinisms. The notification system should attempt to reuse as much of it as possible.

Project Notifications

Project notifications is an umbrella feed which covers several different pieces of information including:

  • Project Messages
  • Project News
  • Private Messages
  • Friend Requests
  • Friend Confirmations
  • Forums
  • Forum Threads

This functionality is currently implemented using the following link:

http://<project_url>/notify_rss.php

The following changes should be made:

  • Each item should belong to one or more categories the client software can use to filter on.

NOTE: This whole feature area should be audited. I would be surprised if 1% of the volunteer population even uses it, after this whole feature is completed 100% of the active host population will be using it.

Database queries should be batched and referenced tables should be converted from MyISAM to InnoDB, whole table locks will cause both BOINC clients and the website to stall depending on which operation(s) are in play.

Preliminary investigation reveals this could be a problem area for us, one query is issued to return all the notifications, and then a new query is issued for each notification to get the details.

A better strategy, using the same schema, is to issue a feeler query that’ll return hints as to which batch queries to issue. Each positive hint will cause a new query to be issued that uses a join to merge all notification records of a certain type with the details of that type.

For instance if a volunteer has 50 private messages the current scheme would result in a minimum of 51 queries issued against the database, the proposed scheme should result in 2 queries against the database. Things get progressively worse the more engaged the volunteer is, 50 private messages and 10 threads being watched would result in 61 queries issued in the current scheme, while only 3 queries would be issued in the proposed scheme.

It is also important to note that the effect of the numbers increase in proportion to the number of machines attached to the project.

Project Messages

Project messages are messages the project would like to see and should be personalized in some way.

Ideally when a volunteer attaches to a project they would receive a welcome message as well as a few links to useful information about the project.

Other useful messages might be milestones and anniversaries. Either could contain a link to a certificate generated on demand that the volunteer could print out.

guid http://<project_url>/notify/<notifyid>
category Message
boinc_project <project_friendly_name>

Project News

guid http://<project_url>/news/<datestamp>
category News
boinc_project <project_friendly_name>

Private Messages

guid http://<project_url>/notify/<notifyid>
category Private Message
boinc_project <project_friendly_name>

Friend Requests

guid http://<project_url>/notify/<notifyid>
category Friend Request
boinc_project <project_friendly_name>

Friend Confirmations

guid http://<project_url>/notify/<notifyid>
category Friend Confirmation
boinc_project <project_friendly_name>

Forums

guid http://<project_url>/notify/<notifyid>
category Forum Update
boinc_project <project_friendly_name>

Forum Threads

guid http://<project_url>/notify/<notifyid>
category Thread Update
boinc_project <project_friendly_name>

BOINC Action Feed

The BOINC Action feed stream is a special in memory RSS feed the BOINC Client software maintains for informing the volunteer about various conditions.

Events that would be added to the stream would be low disk space issues, low memory issues, missing resources like GPUs, and anything else that cannot automatically be taken care of. Network connectivity issues should only be displayed if the automatically connect and automatically disconnect preferences are not set.

Items in the feed can be generated by the BOINC Server Scheduler or the BOINC Client itself.

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

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.

Example:

<scheduler_reply>
    <notification_feeds>
        ...
    </notification_feeds>
    <channel>
        ...
    <channel>
</scheduler_reply>

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

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.

BOINC Core Client

Feed List

Feeds will be added and removed from the feed list at the end of a scheduler operation.

New items are items in which there is not already an entry in the existing list.

Old items are items that are in the existing list and do not have an entry in the scheduler response.

Feeds

Periodically the client will loop through the feed list and download a feed update. The feed update will be stored in a temporary file and any new items will be added to and old items will be deleted from the existing feed list.

Feed updates are required when the current_time > (last_update + update).

New items are items in which there is not already a matching guid in the existing list.

Old items are items that are marked deleted in the existing list and do not have an entry in the feed update.

Feed Storage

All data related to the notification system will be stored in a directory off of the main data directory.

Item Naming convention
Feed directory feeds
Feed list feed_list.xml
Feed "feed_" + escape_project_url(feed_url) + ".xml"

GUI RPCs

get_feeds()

Enumerates all the feeds for a given project as well as provides the properties for a given feed.

Parameters:

Parameter Type Meaning
project_url string Specify which project should the feed metadata be returned for.

Notes:

  • This RPC should not require authentication.
  • If project_url is empty an error should be returned.

get_feed()

Enumerates all the feed items for a given feed as well as provides the properties for a given feed item.

Parameters:

Parameter Type Meaning
project_url string Specify which project should the feed metadata be returned for.
feed_url string Specify which feed should the feed items be returned for.

Notes:

  • If both project_url and feed_url are empty, the BOINC Action Feed stream is returned.
  • Requests for private feeds should return an error.
  • This RPC should not require authentication.

get_private_feed()

Enumerates all the feed items for a given feed as well as provides the properties for a given feed item.

Parameters:

Parameter Type Meaning
project_url string Specify which project should the feed metadata be returned for.
feed_url string Specify which feed should the feed items be returned for.

Notes:

  • This RPC requires authentication.

set_feed_item_option()

Sets a given property for a specific feed item.

Parameters:

Parameter Type Meaning
project_url string Specify which project should the feed metadata be returned for.
feed_url string Specify which feed should the feed items be returned for.
guid string Specify which feed item should be changed.
read bool Item has been read.
deleted bool Item has been deleted.

Notes:

  • This RPC requires authentication.

BOINC Manager

Options Dialog

BOINC Manager Options Dialog

The network reminder interval option will be renamed to action notification reminder interval. A new notification reminder interval will be added for dealing with non-action related notifications and it will be called notification reminder interval.

NOTE: We will need to present a better mechanism than the slider for determining the reminder interval, at present we cap it at two hours. I would like to set the high water mark at 1 week for the notification reminder interval. Maybe a drop-down combo box will work better in that we can scale the selection.

Taskbar Notifications

Taskbar example

Once every notification reminder interval the current list of feeds is checked for any new or unread feed items and if any are detected it should tell the volunteer by way of a balloon.

Advanced View

Simple View

TBD

BOINC Screensaver

The default BOINC screensaver should only display the BOINC Action feed if there is anything to display. If the BOINC Action feed is empty then it should display at random different feed items from the various project news feeds. A new item should be chosen at random every minute.

Projects are encouraged to consume their own feeds and display them in whatever manor fits with their graphics application.

At no time should a screensaver or graphics application attempt to display feeds that have been marked private.

Attachments (2)

Download all attachments as: .zip