| 49 | | Some of the URLs may contain the user's authenticator. |
| | 51 | Whatever the source, notices have the following attributes: |
| | 52 | {{{ |
| | 53 | struct NOTICE { |
| | 54 | int seqno; |
| | 55 | bool private; // requires authentication |
| | 56 | char category[256]; |
| | 57 | std::string description; |
| | 58 | double create_time; // when notice was created |
| | 59 | double arrival_time; // when notice arrived at client |
| | 60 | char url[256]; |
| | 61 | }; |
| | 62 | }}} |
| | 63 | |
| | 64 | The following GUI RPCs return notices : |
| | 65 | {{{ |
| | 66 | get_notices( // requires authentication |
| | 67 | int seqno, // return only notices with this seqno > this |
| | 68 | vector<NOTICE>& |
| | 69 | } |
| | 70 | |
| | 71 | get_notices_public() |
| | 72 | // returns only non-private notices, doesn't require authentication |
| | 73 | // screensavers use this |
| | 74 | }}} |
| | 75 | |
| | 76 | The client stores the set of all notices in a deque, ordered by seqno. |
| | 77 | |
| | 78 | === Server and client notices === |
| | 79 | |
| | 80 | Server and client notices are added to the deque. |
| | 81 | If 60 secs have elapsed since last write, |
| | 82 | the server and client notices are written to a disk file. |
| | 83 | |
| | 84 | === Notice feeds === |
| | 85 | |
| | 86 | Scheduler replies include a list of RSS feeds to be used as notice sources: |
| | 87 | {{{ |
| | 88 | <scheduler_reply> |
| | 89 | ... |
| | 90 | <notice_feeds> |
| | 91 | <notice_feed> |
| | 92 | <name>...</name> |
| | 93 | <url>...</url> |
| | 94 | <poll_interval>x</poll_interval> |
| | 95 | <append_last_guid>0|1</append_last_guid> |
| | 96 | </notice_feed> |
| | 97 | ... |
| | 98 | </notice_feeds> |
| | 99 | </scheduler_reply> |
| | 100 | }}} |
| | 101 | |
| | 102 | * url: where to poll |
| | 103 | * poll_interval: how often to poll |
| | 104 | * append_last_guid: if true, append "&last_guid=x" to url |
| | 105 | (server will return only newer items) |
| | 106 | |
| | 107 | If <notice_feeds> is present in a scheduler reply, |
| | 108 | the client adds and/or removes feeds from the project. |
| | 109 | |
| | 110 | The client periodically polls each URL. |
| | 111 | If append_last_guid is set, it scans the deque for the most recent notice and passes its GUID. |
| | 112 | For each item returned, it checks whether the GUID exists in the deque, |
| | 113 | and if not appends it. |
| | 114 | If any items were added, it writes this feed's notices to a disk file. |
| | 115 | |
| | 116 | Some of the URLs may contain an authenticator. |
| 57 | | RSS items have two timestamps: |
| 58 | | |
| 59 | | * source timestamp: for remote items, the source's timestamp |
| 60 | | * client timestamp: when the client first received this item |
| 61 | | |
| 62 | | RSS items may contain a GUID. |
| 63 | | |
| 64 | | The client maintains a "last source timestamp" for each feed. |
| 65 | | Each feed request can optionally containt this timestamp, |
| 66 | | and the feed returns only items with later timestamp. |
| 67 | | |
| 68 | | GUIs poll items based on client timestamp. |
| 69 | | |
| 70 | | == Implementation == |
| 71 | | |
| | 123 | On startup, the client reads the client/server notice file |
| | 124 | and all the feed files into the deque. |
| | 125 | It then sorts the deque by decreasing arrival_time |
| | 126 | and assigns sequence numbers. |
| 77 | | |
| 78 | | === Feed List === |
| 79 | | |
| 80 | | Scheduler replies can include a feed list. |
| 81 | | Example: |
| 82 | | {{{ |
| 83 | | <notification_feeds> |
| 84 | | <feed> |
| 85 | | <url>http://www.example.com/notify_rss.php</url> |
| 86 | | <name>Project Notifications</name> |
| 87 | | <update>86400</update> |
| 88 | | </feed> |
| 89 | | <feed> |
| 90 | | <url>http://www.example.com/science_blog_rss.php</url> |
| 91 | | <name>Science Blog</name> |
| 92 | | <update>86400</update> |
| 93 | | </feed> |
| 94 | | </notification_feeds> |
| 95 | | }}} |
| 96 | | |
| 97 | | Property table: |
| 98 | | update:: Number of seconds in between updates |
| 99 | | application_only:: Feed is used by the project application and should not be shown in BOINC Manager or the BOINC Screen saver. |
| 100 | | The contents of the feed should be written to the init_data.xml file in the slot directory before the application is launched. |
| 101 | | |
| 102 | | BOINC has several built-in community defining features and feedback mechinisms. The notification system should attempt to reuse as much of it as possible. |
| 156 | | |
| 157 | | == BOINC Core Client == |
| 158 | | |
| 159 | | |
| 160 | | === Feed Storage === |
| 161 | | All data related to the notification system will be stored in a directory off of the main data directory. |
| 162 | | |
| 163 | | || Item || Naming convention || |
| 164 | | || Feed directory || feeds || |
| 165 | | || Feed list || feed_list.xml || |
| 166 | | || Feed || "feed_" + escape_project_url(feed_url) + ".xml" || |
| 167 | | |
| 168 | | === GUI RPCs === |
| 169 | | |
| 170 | | ==== get_feed() ==== |
| 171 | | Enumerates all the feed items for a given feed as well as provides the properties for a given feed item. |
| 172 | | |
| 173 | | Parameters: |
| 174 | | || Parameter || Type || Meaning || |
| 175 | | || project_url || string || Specify which project should the feed metadata be returned for. || |
| 176 | | |
| 177 | | '''Notes''': |
| 178 | | * If both project_url and feed_url are empty, the BOINC Action Feed stream is returned. |
| 179 | | * Requests for private feeds should return an error. |
| 180 | | * This RPC should not require authentication. |
| 181 | | |
| 182 | | ==== get_private_feed() ==== |
| 183 | | Enumerates all the feed items for a given feed as well as provides the properties for a given feed item. |
| 184 | | |
| 185 | | Parameters: |
| 186 | | || Parameter || Type || Meaning || |
| 187 | | || project_url || string || Specify which project should the feed metadata be returned for. || |
| 188 | | |
| 189 | | '''Notes''': |
| 190 | | * This RPC requires authentication. |