Preferences implementation

General preferences

General preferences are represented by an XML element of the form:

<global_preferences>
    <source_project>%s</source_project>
    <source_scheduler>%s</source_scheduler>
    <mod_time>%d</mod_time>
    <run_on_batteries/>
    <run_if_user_active/>
    <suspend_if_no_recent_input>%f</suspend_if_no_recent_input>
    <start_hour>%f</start_hour>
    <end_hour>%f</end_hour>
    <net_start_hour>%f</net_start_hour>
    <net_end_hour>%f</net_end_hour>
    <leave_apps_in_memory/>
    <confirm_before_connecting/>
    <hangup_if_dialed/>
    <dont_verify_images/>
    <work_buf_min_days>%f</work_buf_min_days>
    <work_buf_additional_days>%f</work_buf_additional_days>
    <max_cpus>%d</max_cpus>
    <cpu_scheduling_period_minutes>%f</cpu_scheduling_period_minutes>
    <disk_interval>%f</disk_interval>
    <disk_max_used_gb>%f</disk_max_used_gb>
    <disk_max_used_pct>%f</disk_max_used_pct>
    <disk_min_free_gb>%f</disk_min_free_gb>
    <vm_max_used_pct>%f</vm_max_used_pct>
    <ram_max_used_busy_pct>%f</ram_max_used_busy_pct>
    <ram_max_used_idle_pct>%f</ram_max_used_idle_pct>
    <idle_time_to_run>%f</idle_time_to_run>
    <max_bytes_sec_up>%f</max_bytes_sec_up>
    <max_bytes_sec_down>%f</max_bytes_sec_down>
    <cpu_usage_limit>%f</cpu_usage_limit>
    <day_prefs>                 
        <day_of_week>%d</day_of_week>
        <start_hour>%.02f</start_hour>
        <end_hour>%.02f</end_hour>
        <net_start_hour>%.02f</net_start_hour>
        <net_end_hour>%.02f</net_end_hour>
    </day_prefs>
    <venue name="%s">
        [...]
    </venue>
</global_preferences>

The first set of preferences are the default; each set of venue-specific preferences is enclosed in a <venue> element. The optional <source_project> and <source_scheduler> elements indicate the source of the preferences. On the client, the global prefs are stored in global_prefs.xml (present only if they've been obtained from a server). <day_prefs> appears once for each day with customised times.

A scheduler RPC request includes global_prefs.xml if it's present. If the request includes global prefs, the scheduler installs them in the DB if the DB copy is missing or older. If the DB copy is newer, it includes it in the reply. If the request has no prefs and they're present in the DB, they're included in the reply.

When handling a scheduler RPC reply that includes global prefs, the client writes them to global_prefs.xml, prepending the project and scheduler URLs is absent.

Project preferences

Project preferences are represented by an XML element of the form:

<project_preferences>
    <resource_share>%d</resource_share>
    <project_specific>
        [...]
    </project_specific>
    <allow_beta_work>%d</allow_beta_work>
    <allow_non_preferred_projects>%d</allow_non_preferred_projects>
    <apps_selected>
        <app_id>%d</app_id>
    </apps_selected>
    <venue name="%s">
        <resource_share>%d</resource_share>
        <project_specific>
            [...]
        </project_specific>
        <allow_beta_work>%d</allow_beta_work>
        <allow_non_preferred_projects>%d</allow_non_preferred_projects>
        <apps_selected>
            <app_id>%d</app_id>
        </apps_selected>
    </venue>
</project_preferences>

On the client, the project prefs are stored in a file account_XXX.xml, which has the additional elements.

A scheduler RPC reply always includes project prefs.

When handling a scheduler RPC reply, the client writes them to the account_X.xml file, prepending the master URL and authenticator.