-
Notifications
You must be signed in to change notification settings - Fork 443
Notifications
The goal is to create a way to notify users of events that require their attention or are likely to interest them. Examples include:
- Conditions in the core client requiring user attention (messages with mode MSG_USER_ERROR)
- New client version available
- High-priority messages from the scheduler (e.g., no jobs because too little disk allocated, wrong driver version, etc.)
- Web notifications such as friend request or confirm, private message, posting to subscribed thread, etc.
- Project news (scientific, credit milestones, etc.)
- An RSS feed specified by the project or the user.
The Messages tab will be renamed the "Event Log". It will be available via a menu item rather than a tab.
Notices will be shown in a new Notices tab. They will be displayed in HTML. The 10 most recent notices will be displayed, with a button to show all notices in the last month. Most recent notices are on top. Like messages, each will have a timestamp and a project. Buttons will let users filter by project and select notices.
When there is a new notice, a balloon appears over the system tray icon for 10 seconds. It will show the type of the notice. Clicking on the balloon will open the Manager in the Notices tab.
The default BOINC screensaver will display new notices. Notices are classified as "private" and "public"; e.g., private messages and friend requests are private. The screensaver will show only public messages.
The client collects notices and delivers them via GUI RPC. There are three general sources of notices :
- RSS feeds
- Server notices (<message> elements in scheduler replies)
- Client notices (from calls to msg_printf with priority MSG_USER_ERROR)
Whatever the source, notices have the following attributes:
struct NOTICE {
int seqno;
bool private; // requires authentication
char category[256];
std::string description;
double create_time; // when notice was created
double arrival_time; // when notice arrived at client
char url[256];
};
The following GUI RPCs return notices :
get_notices( // requires authentication
int seqno, // return only notices with this seqno > this
vector<NOTICE>&
}
get_notices_public()
// returns only non-private notices, doesn't require authentication
// screensavers use this
The client stores the set of all notices in a deque, ordered by seqno.
Client notices include:
- error msg from account manager
- new version available
- can't write state file
- HTTP_PROXY env var exists but doesn't specify proxy
- syntax error in app_info.xml
- can't resolve hostname in remote_hosts.cfg
- syntax error in cc_config.xml
- need network connection
Server notices include:
- invalid or missing account key
- outdated code signing key
- need newer client version
- unsupported OS or CPU type
- unsupported install type (Vista)
- too little disk
These notices are not saved across BOINC restarts, because in many cases the transient problem may have been fixed, and if not the notice will eventually be regenerated.
Server and client notices are added to the deque. If 60 secs have elapsed since last write, the server and client notices are written to a disk file.
Scheduler replies include a list of RSS feeds to be used as notice sources:
<scheduler_reply>
...
<notice_feeds>
<notice_feed>
<name>...</name>
<url>...</url>
<poll_interval>x</poll_interval>
<append_last_guid>0|1</append_last_guid>
</notice_feed>
...
</notice_feeds>
</scheduler_reply>
- url: where to poll
- poll_interval: how often to poll
- append_last_guid: if true, append "&last_guid=x" to url (server will return only newer items)
If <notice_feeds> is present in a scheduler reply, the client adds and/or removes feeds from the project.
The client periodically polls each URL. If append_last_guid is set, it scans the deque for the most recent notice and passes its GUID. For each item returned, it checks whether the GUID exists in the deque, and if not appends it. If any items were added, it writes this feed's notices to a disk file.
Some of the URLs may contain an authenticator. In response to a scheduler RPC with a weak authenticator, the scheduler supplies only URLs for public notices, and passes the weak authenticator.
On startup, the client reads the client/server notice file and all the feed files into the deque. It then sorts the deque by decreasing arrival_time and assigns sequence numbers.
Strings of the form _(...) in notice title and content are localizable.
This feed generates
- Project News
- Private Messages
- Friend Requests
- Friend Confirmations
- Posts to subscribed forum threads
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.
The URL is:
http://<project_url>/notices.php?userid=x&auth=y
TBD
The ProjectNotices page describes an alternative mechanism for delivering notifications.