= Remodel of computing preferences =

== Problems with the current system ==

 * Too complex: non-technical users see lots of prefs,
   with technical descriptions that many don't understand.
 * Not complex enough: many reasonable policies can't be expressed,
   such as different CPU throttling or network bandwidth limit as a function
   of time of day or user active.
 * Inconsistency between manager GUI and web interface.
 * Code complexity, especially in web code.

This document proposes a redesign of the prefs system

== Top-level interface ==

The top-level interface should consist of four choices:

 * Standard
 * Maximum computing
 * Energy-saver
 * Custom

The first 3 would be predefined sets of prefs;
e.g. Energy-saver would compute only when active, and would do CPU throttling.

== Custom prefs ==

Prefs can be classified as

 * '''dynamic''': those that might change from one moment to the next,
 e.g. based on activity or time of day.
 This include:
  * Do computing?
  * Do GPU computing?
  * Suspend computing if CPU usage above X
  * Leave suspended tasks in memory
  * Use at most X% of processors
  * CPU throttling
  * Checkpoint interval
  * Limit on swap space usage
  * Limit on RAM usage
  * Use network?
  * max download and upload rates
 * '''static''': those that don't change
  * "In use" time interval
  * Disk prefs (max use GB, max use %, min free GB)
  * Network connection interval
  * Additional work parameter
  * Transfer at most X MB every N days
  * skip image file verification

The following could be either static or dynamic;
I'd prefer to make them static.

 * Suspend work while on batteries?
 * CPU scheduling period
 * Confirm before connecting to Internet?
 * Disconnect when done?

Let's call a set of dynamic prefs a '''configuration'''.
The idea is that a preference set consists of

 * A single set of static prefs
 * One or more configurations;
 e.g. a config for "in use" and another config for "not in use".
 Or a config for time/day in a certain range, and another config
 for outside of that range.

This raises a question: if we allow config selection
based on both in-use and time-of-day,
which one has precedence?
My inclination is to allow selection either by in-use
or time-of-day, but not both.

== Time of day specification ==

We may as well generalize time-of-day spec
to allow selection on a per-hour basis, rather than contiguous periods.

== Custom prefs: summary ==

If the user selects Custom, the editing GUI shows:
 * the static prefs
 * a radio button selection of
  * same prefs all the time
   * if selected, a single set of dynamic prefs
  * different prefs depending on time of day/week
   * if selected, a time-of-day selection interface,
   and two sets of dynamic prefs
  * different prefs depending on whether computer is in use
   * if selected, two sets of dynamic prefs

== Venues ==

== Backwards compatibility ==

== Possible additions ==

The BOINC client config file (cc_config.xml) has some items
that maybe should be prefs.
These include:

Dynamic:
 * exclusive apps
 * exclusive GPU apps

Static:
 * none that I can think of

== Possible deletions ==

Does anyone actually use the following?
They could be moved to cc_config.xml

 * "In use" interval (2 minutes should be OK)
 * CPU scheduling period
 * leave apps in memory (should default to No)
 * Checkpoint interval
 * Limit on swap space usage
 * network connection interval and work buffer
 (these should by computed automatically based on
 actual behavior)