- Refactor the JavaScript code (to use more appropriate idioms etc.)

- Replace some of the current database queries with more efficient
  ones (e.g. consider denormalizing to get rid of expensive joins).

- In the time series plot, highlight the current change, the difference
  tolerance, and the stability tolerance by means of two rectangles.

- Allow for specifying a difference- and stability tolerance per benchmark.

- Allow for an alternative database backend (like PostgreSQL) to be specified
  when starting the bmserver (default should still be SQLite).

- Add support for more browsers (in particular Qt-based ones like
  QWebView and konqueror). (The main challenge here would probably be to
  come up with useful alternatives to the HTML canvas tag for 2D graphs.)

- Add a way to annotate the history (for a certain context) so that
  history before and after e.g. a system upgrade can be handled separately.
  This could be implemented by generalizing history into segments (by the
  default there is only one). The user could then choose either to compare
  results within a specific segment (normally the latest one), or ignore
  segment boundaries altogether.
  ALTERNATIVELY, we could rely on system upgrades to be captured in the host
  entity: Results after a system upgrades need to be registered with a
  different host name. A 'description' attribute could be introduced for the
  host entity for keeping details about the system.

- Automatic regression notification. Notifications could be sent either
  directly to relevant/subscribing persons (through an email etc.), or
  indirectly by creating JIRA tasks, which in turn could trigger notifications
  to relevant people. Other ideas?

- In "branch 2" and "file" modes, consider if the "current change" and "trend"
  columns of the primary branch should be shown in addition to the
  "difference" column.

- Allow for comparison wrt. other context entities than branches.
  It may for example be useful to compare results produced under (slightly)
  different system (hw/sw) environments. Currently, such environments are
  captured in the 'host' entity, i.e. two results associated with the same
  host are assumed to have been produced under the exact same system
  environment (regardless of VM usage).

- Allow for recording more than one result per snapshot. This is a useful
  option for increasing the statistical confidence (i.e. the final result
  could typically be the median of the sub-results).

  (Note: currently, the result for a given snapshot is always the latest one
  recorded for that snapshot (the existing one is overwritten)).

- Use QXmlStreamReader instead of QDomDocument.

- Make web app behave sensibly for an empty result database.