Help wanted - programming

BOINC needs volunteers to help with software development. BOINC consists of several areas, each with some required technical skills:

Area	Skills needed
Client	C++, system programming
Manager	C++, WxWidgets, GUI and graphical design, usability
Server programs	C++, system programming, database design, MySQL
Web features	PHP, CSS, web design, database design, MySQL
Unix build system	autoconf, automake

The University of California holds the copyright on all BOINC source code. By submitting contributions to the BOINC code, you irrevocably assign all right, title, and interest, including copyright and all copyright rights, in such contributions to The Regents of the University of California, who may then use the code for any purpose that it desires.

Finding tasks

There are several ways to get tasks to work on:

• Scan the BOINC bug database for unresolved bugs or feature requests.
• Read the list of proposed features on this page.
• Scan the BOINC message boards for ideas.

Coordinating your work

Once you pick out a task:

• Look at the source code and think about how you would implement the task.
• Read about the BOINC software and development process.
• Communicate with the area owner or David Anderson, and reach agreement on exactly what you're going to do and how. Don't start coding until you do this.

Submitting your work

• Submit your work (as diffs or files) to the area owner, so that they can evaluate it and possibly check it in.
• If you are working on a large task and want to stay current with the trunk, ask us to create an SVN workspace for you.
• Once you've contributed a certain amount of work, we'll give you SVN write access.

Proposed features

The following development projects are available (Note: please do not add items to these lists. Suggest new items in the boinc_dev email list.)

Web features

Easy:

• Add a Reset button to prefs (both general and project)
• 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). #595
• Change whole-page caching to data caching to eliminate problem with wrong translations. #598
• Change update_profile_pages.php (and others) to use single join queries instead of lots of secondary select queries. #599
• Convert all PHP code to use the new database abstraction layer. #600
• Combine user page and profile. #601
• Change all ops/ web pages to require login by a user with admin privileges (rather than .htaccess). #602
• Change default Q&A page to refer BOINC-specific questions to BOINC web site. #603
• Convert team name HTML and team description to BBcode. #604
• Use rich-text editing widget (e.g. Yahoo) wherever we allow BBcode. #392

Medium:

• Add a mechanism where joining a team or group requires approval of an admin. #605
• Groups (sub-teams). New DB table with name, description, team ID, flags, forum ID. Group membership table. #606

Difficult/Complex?:

• Repackage the BOINC web code (PHP) as a Drupal module.
• 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
• Preferences: add a simplified interface where there are discrete choices (this applies to both web and GUI):
  • Standard
  • Max work
  • Min interference
  • Green
• Preferences: Currently there are time of day/week controls for gross features - whether to compute, whether to communicate. Extend this so that all relevant preferences can be controlled by time of day/week.

• Propagate profiles between projects. #608
• Same for forum preferences.
• Add new profile features: #609
  • list of recent posts and threads this person created, on this and other projects.
  • other features from social networking sites?
  • Add ‘referral’ mechanism: new user creates account, enters email of ‘referrer’ (or goes to URL that has it embedded). Give referrer a fraction of credit (or a 1-time bonus). List referrals on user page (show only those still active). Add new referral table to DB.
• Make it easy for teams to offer a client download that features their skin, and pre-register the user on that team for any projects he attaches to. #610

Applications

Easy:

• Create Makefiles and project files to build the sample applications using MinGW and Dev-C++.

Medium:

• Write example FORTRAN application and Makefiles/ project files.

Difficult/Complex?:

• Write an example compound application (and suggest API revisions to make this easier).
• Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR).
• Java support: core client checks for the existence of JVM, reports version to scheduler. Write Java wrapper (runs JVM, gives it jar files). Note: Sztaki has already done some part of this.
• Same, .NET

Core client

Medium:

• Add an "expiration delay" for files: delete them only after they haven't been used for X time.
• 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).
• Core client monitors total CPU usage, limits its own CPU usage so that total is < 100%.
• 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.
• GUI RPC to tell apps to checkpoint and quit.
• Keep track of upload/download sizes, show weekly/monthly transfer totals.

Hard:

• Have the core client sense CPU temperature and throttle CPU if it goes too high. ​Open-source software for collecting sensor data (on Linux) is available.
• Windows: get proxy config info directly from the OS.
• After an applications exits or is killed (for whatever reason) make sure (after a few second delay) that its subprocesses are gone too. Don't restart the job until this happens. Unix: use process groups and killpg().
• More generally: make a better state machine for shutting down apps: tell them to checkpoint, wait a little, tell them to quit, clean up straggler processes.
• Same, but for suspend: if we tell a client to suspend and it's still using lots of CPU after a few seconds, abort it (or something).
• Integrate BitTorrent (​libtorrent?) with the core client (Janus Kristensen is working on this).
• Log result start/ends (for use by 3rd-party software like BoincView).
• Prevent disk space usage from exceeding user preferences, and enforce resource shares, with file deletion according to project policy.
• Make messages of class MSG_USER_ERROR translatable. #153
• Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate.

Installer

• Check if host is configured to go into Standby mode after X idle minutes. If so, ask user if they want to let BOINC run for X minutes, then go into standby right after that.

BOINC Manager

Easy:

• Show credit numbers (especially totals) with thousands-groups separators (e.g., commas)
• If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere.

Hard:

• The BOINC manager optionally polls notification RSS feeds and shows new items as alerts.
• Turn off alerts (Rom Walton is working on this).

Server/Back? End

Easy:

• Add a -h/--help option to all back end programs that explains what it does and gives usage. (already done?)
• 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.
• Add a mechanism to recover from situations where the scheduler fails to send its reply message.
  • Add a reply_pending field to host table. Set at start of scheduler, clear after reply message sent.
  • If get a request from host with reply_pending==1, scan for lost results

This would replace the <resend_lost_results> mechanism.

• XML stats: add lat/long to user record?

Medium:

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

Hard:

• Add support for MPI-type applications: try to schedule all the jobs in a batch more or less simultaneously. May require:
  • NCPUs jobs per host
  • Notion of "infinite priority" (start right away). May suffice to have zero delay bound.
  • feeder orders by batch
• Implement a mechanism so that server software detects incompatible database format. (related to #715)
• 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).
• ?? how to select an app version based on contents of app_info?

This could be used, e.g., to do app-specific benchmarking, to gather info on the host hardware or software configuration, or to periodically check the numerical hardware.