Development projects

We need volunteers to help with software testing and development. If you have one or more of the relevant technical skills (C++ system programming, PHP/MySQL Web development, wxWidgets programming, autoconf/automake expertise, etc.) you may be able to help us maintain and enhance BOINC.

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.

To get started, read about the BOINC software development process. Find a small bug fix or enhancement to do (look at the BOINC bug database, the email lists, or message boards for ideas). Look at the source code and think about how you would implement it. Then communicate with the area owner, sketching what you want to do and how. Work with the the area owner to carry out and check in the work.

The following development projects are available:

Web Interface

Front-end

Requires front-end specialists with detailed knowledge and experience of markup and styling.

Requires colaboration between front-end specialists and back-end developers when changes to back-end/features affect front-end behaviour (to ensure correct front-end code).

Medium:

• Some kind of ‘Quality Assurance’ process to check any changes to front-end are appropriate (far easier to have poor front-end code be submitted and missed than back-end code; bad back-end code generally doesn't work and/or breaks something, poor front-end code is tollerated by browsers).
• All styling declarations to be contained in external files
• Separation of structure/content and presentation — removal of deprecated presentational markup elements (that's what CSS is for).
  • Separate “General” and “Project-specific” CSS files. The idea being that a project can make customisations in the Project-Specific file, over-riding the “general” styling, while still being able to easilly “update/upgrade” the general styling CSS file needed for basic layout and such. This is to help projects avoid having to ‘back-up’ their customisations to avoid them being over-written during a server upgrade, thus encouraging each project to adopt a ‘unique’ look & feel for better identity (many projects don't change the default presentation, so the web-interface of many projects looks the same. The difficulty in making, and maintaining customisations while still trying to upgrade BOINC server versions is likely a reason most don't bother; afterall, what's the point if they're just going to be over-written at the next upgrade?).
• Typography corrections/improvements
• Quality copy-writing to enhance readability and clarity of content

Difficult/Complex?:

• Information Architecture — eg creating a appropriate, stable URL structure, allowing for future expansion and change (eg use of HTTP default documents rather than current practice).
  • Any changes to URL structure require (permanent) redirects from all previous locations to all new locations.
• Valid Markup & style declarations — Importance of valid code: “​Why We Won't Help You”, ​How User-Agents Handle Tag-Soup.
  • Should aim for HTML v4.01 Strict (XHTML served with the correct MIME-type/content-type doesn't have sufficient support, modern HTML authoring techniques are perfectly capable, adequate, suitable, and appropriate).
  • If Strict isn't reasonably attainable (very few reasons why apart from time constraints to correct poor design/implementation), then aim for Transitional as an intermediate step, so that the code will at least be valid.
  • Closing tags
  • Correct nesting of elements: closing tags in the opposite order to opening, eg closing the most recently opened first: <1><2><3></3></2></1>
  • Mark-up authored in such a way as to allow presentation to be radically changed via CSS — involves structure * ID/class values based on purpose rather than presentation/appearence.
• Semantic Markup — marking-up things based on what they are, not the default appearence of certain elements. For example: using <blockquote>…“quoted” text…</blockquote> for indentation is inappropriate. Block-quotes should be marked as <blockquote><p>…actual block-quote…</p></blockquote> and nothing else. In this example, if indentation is required then CSS should be used to apply styling to an appropriate element (a regular paragraph (<p>…Paragraph text…</p>) would probably be suitable unless the element isn't actually a paragraph.
• Accessibility
  • Replacing table-based layouts with CSS positioning
  • More semantic mark-up (see semantic markup item)
  • Using appropriate units in style declarations to enable resizing of text based on user's preferences in browser.
  • Unobtrusive, accessible use of ECMAScript (JavaScript), implemented via progressive enhancement and DOM Scripting methods. ​Scripting is not always available and can not be relied upon (for many reasons, the majority being outside the user's control), and the back-end needs to be able to provide same functionality (albeit less elegent/sophisticated) when scripting isn't available for whatever reason. A simple example would be back-end form input validation when scripting isn't available to protect against garbage/bogus form data and provide feedback to user.
• Usability
  • Including error-messages and similar
• Proper navigation model
  • Navigation bar/panel on common pages (rather than always having to (or only being able to) go back to “Home” and then navigate to desired section from there).
  • Interface designer to establish the appropriate navigation options for each page.
• HTTP efficiency
  • Content-Encoding
  • Providing correct Last-Modified and ETag headers to enable conditional GET requests.
    • Back-end support to enable “HTTP 304 Not Modified” responses to be sent when content hasn't changed based on conditional GET request(s).
  • More ‘agressive’ caching for content who's frequency of change is predictable (such as images).

Forum

• Accessibility
  • Table mark-up to better indicate headers and relationship between cells and headers (mostly involves changing the template used by the back-end to generate thread tables)
    • A side-advantage is that by indicating such things allows user agents to render a table as soon as it starts getting data, rather than having to wait for the entire table to begin calculating the width, this will result in significant rendering improvements.
  • Checking/validating user-input
    • Make authoring accessible, semantic forum posts as easy as possible (the markdown syntax would be a good candidate).

• HTTP Functionality
  • Use correct type of HTTP Request based on purpose/function
    • GET requests should not change anything (as per the ​HTTP/1.1 RFC). Currently the Subscribe/Unsubscribe? functions use regular links (resulting in GET requests) to change subsciption status, instead a POST request should be required (eg making the funcion unavilable via GET) to indicate that the (un)subscribe function changes something and isn't just fetching a page.

Back-end

Requires advanced knowledge of PHP and MySQL.

Easy:

• Colaboration/consultation with front-end specialist(s) when wanting to alter front-end code due to back-end changes (see front-end section).
• Convert PHP code to use the new database abstraction layer.
• Combine user page and profile
• Change the ops/ web pages to require login by a user with admin privileges.
• Change default Q&A page to refer BOINC-specific questions to BOINC web site
• As much as possible; separate back-end and front-end code, to enable front-end specialists to edit front-end code without having to know about, or deal with back-end code.

Medium:

• Back-end must reliably produce valid front-end code (mark-up).
• Add a mechanism where team members can be designated as ‘admins’, and have some of the powers of the founder.
• Add a mechanism where joining a team or group requires approval of an admin.
• Groups (sub-teams). New DB table with name, description, team ID, flags, forum ID. Group membership table.

Difficult/Complex?:

• Propagate profiles between projects. When create or edit profile, if attached to other projects, show ‘propagate changes’ page, with checkboxes for other projects (must have same password on other projects). Add web RPCs for updating profile (args: user ID, profile, password hash). Implement this so that page doesn't block waiting for replies from RPCs. NOTE: this may not be a good idea — spammers could exploit it.
• Same for forum preferences
• Add new profile features:
  • ‘Buddy lists’
  • 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.

Applications

Easy:

• Create Makefiles and project files to build the sample applications using MinGW and DevC++.

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
• Distributed Python: Borrow or invent a notation for master/slave execution in Python. Develop a system that implements this on BOINC, i.e., creates WUs and applications, and harvests the results.

Core client

(Requires advanced C++ system programming experience) Medium:

• 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).
• Don't enforce RAM limits unless free RAM is low
• GUI RPC to tell apps to checkpoint and quit.

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).
• Do potentially slow RPCs and other tasks (such as computing disk usage) in a separate thread.
• 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.
• Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate.
• XML stats: add lat/long to user record?

BOINC Manager

(Requires experience with WxWidgets GUI toolkit) Easy:

• If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere

Hard:

• Properties pages for projects, jobs
• Turn off alerts (Rom's working on this)
• Have the Manager do RPCs in a separate thread.

Server/Back? End

(Requires advanced C++/Unix system programming experience)

Medium:

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

Hard:

• Implement a mechanism so that server software detects incompatible database format
• Scheduler: implement mechanisms so that server:
  • Attempts to send results from the same WU to hosts with similar speed, so that a fast host doesn't have to wait weeks to get credit.
• Implement a ‘benchmark result’ mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results

Please check with area owner or David Anderson before undertaking any of these.