Changes between Version 67 and Version 68 of DevProjects
- Timestamp:
- Oct 12, 2010, 4:23:55 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DevProjects
v67 v68 50 50 Easy: 51 51 * Add a Reset button to prefs (both general and project) 52 * Use CSS instead of HTML for formatting where possible; clean up white.css; improve the look; develop alternative looks (perhaps with the curiously popular rounded corners). #59553 52 * Change whole-page caching to data caching to eliminate problem with wrong translations. #598 54 53 * Change update_profile_pages.php (and others) to use single join queries instead of lots of secondary select queries. #599 55 54 * Convert all PHP code to use [PhpDb the new database abstraction layer]. #600 56 55 * Combine user page and profile. #601 57 * Change all ops/ web pages to require login by a user with admin privileges (rather than .htaccess). #60258 56 * Change default Q&A page to refer BOINC-specific questions to BOINC web site. #603 59 57 * Convert team name HTML and team description to BBcode. #604 … … 64 62 * Groups (sub-teams). New DB table with name, description, team ID, flags, forum ID. Group membership table. #606 65 63 66 Difficult /Complex:67 * Repackage the BOINC web code (PHP) as a Drupal module. 64 Difficult and/or complex: 65 * Repackage the BOINC web code (PHP) as a Drupal module. Being worked on by Einstein@home. 68 66 * Unify preferences (i.e., have the same prefs available on the web as in the Manager, and if possible make the interface look the same). #607 69 67 * Preferences: add a simplified interface where there are discrete choices (this applies to both web and GUI): … … 89 87 Medium: 90 88 * Write example FORTRAN application and Makefiles/ project files. 91 Difficult /Complex:89 Difficult and/or complex: 92 90 * Write an example compound application (and suggest API revisions to make this easier). 93 91 * Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR). … … 103 101 (e.g., subtract the 2 sigma point for both). 104 102 * Add an "expiration delay" for files: delete them only after they haven't been used for X time. 105 * Add a preferences for total download and upload in a month (many Australian ISPs have monthly limits), or per X hours of processing time (see email from Kevin Reed).106 103 * Core client monitors total CPU usage, limits its own CPU usage so that total is < 100%. 107 104 * Monitor working-set size of non-BOINC apps; don't allow total to exceed physical RAM. This could eliminate the need for memory-usage preferences. Note: this might be tricky because parts of a process's working set is shared with other processes. Some study is needed to figure out the best approach. … … 129 126 * Show credit numbers (especially totals) with thousands-groups separators (e.g., commas) 130 127 * If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere. 131 Hard:132 * Turn off alerts (Rom Walton is working on this).133 128 134 === Server /Back End ===129 === Server and Back End === 135 130 136 131 Easy: 137 * Add a --version option to all back end programs that prints their version, from ../version.h. NOTE: this is a client version number; it would be better to print the SVN changeset.138 132 * Add a mechanism to recover from situations where the scheduler fails to send its reply message. 139 133 * Add a reply_pending field to host table. Set at start of scheduler, clear after reply message sent. 140 134 * If get a request from host with reply_pending==1, scan for lost results 141 135 This would replace the <resend_lost_results> mechanism. 136 NOTE: this is not a good design; successful send doesn't imply successful receipt. 142 137 * XML stats: add lat/long to user record? 143 138 144 139 Medium: 145 * Enforce file immutability. I.e., change update_versions and create_work() so that they check if any file is already in the download hierarchy, and if so make sure that it is the same. Use MD5s for efficiency. 146 * When using HR, if the scheduler has sent one result of a WU using a particular app version, it should use the same app version for other results from that WU. Otherwise, when new app versions are released, results may incorrectly be marked as invalid. 140 * Enforce file immutability. I.e., have create_work() check if any file is already in the download hierarchy, 141 and if so make sure that it is the same. Use MD5s for efficiency. 142 * When using HR, if the scheduler has sent one result of a WU using a particular app version, 143 it should use the same app version for other results from that WU. 144 Otherwise, when new app versions are released, results may incorrectly be marked as invalid. 145 NOTE: not really needed; create a new app instead. 147 146 148 147 Hard: 149 * Add support for MPI-type applications: try to schedule all the jobs in a batch more or less simultaneously. May require: 150 * NCPUs jobs per host 151 * Notion of "infinite priority" (start right away). May suffice to have zero delay bound. 152 * feeder orders by batch 148 * Add support for MPI-type applications: try to schedule all the jobs in a batch more or less simultaneously. 149 NOTE: being done by Volpex project from U. of Houston. 153 150 * Implement a mechanism so that server software detects incompatible database format. (related to #715) 154 151 * Add project_specific_info field to host table (text). This stores, for each app, the ID of last reference WU completed, and the info returned by that WU (as part of its stderr output, in a <app_info> tag). 155 * ?? how to select an app version based on contents of app_info? 156 157 This could be used, e.g., to do app-specific benchmarking, 158 to gather info on the host hardware or software configuration, 159 or to periodically check the numerical hardware. 152 ?? how to select an app version based on contents of app_info? 153 This could be used, e.g., to do app-specific benchmarking, 154 to gather info on the host hardware or software configuration, 155 or to periodically check the numerical hardware.
