Core client: data structures

The central data types in the core client are:

PROJECT
APP
FILE_INFO
APP_VERSION
IO_FILE_DESC
WORKUNIT
RESULT
These correspond to the abstractions of the same name. They contain some fields that aren't present on the server side; e.g., FILE_INFO has a field indicating whether the file is present on this host.

Each of these classes has write and parse functions for converting an instance to or from XML. In some cases there are different variants depending on whether the repository of the XML is a scheduling server or the local client_state.xml file.

These structures are linked by pointers; for example, an APP_VERSION has a pointer to its APP.

PREFS
This class is a parsed version of the prefs.xml file; as such it doesn't contain any host-specific information. It contains a vector of partially-populated PROJECT objects, and parsed versions of user preferences.
CLIENT_STATE
This encapsulates the global variables of BOINC on this host. It is a parsed version of client_state.xml, represented as vectors of the basic types. It also includes some transient variables, such as sets of finite-state machines.

Initialization

When the core client starts up (CLIENT_STATE::init()) it parses the prefs file, creating a PREFS object. (If there is no prefs file, it prompts the user for a project and account ID, and creates one.) It then copies the vector of PROJECT objects to CLIENT_STATE.

Next, it parses the client_state.xml file. Any projects in this file but not in prefs.xml are ignored. As it parses objects that link to other objects, it looks up the referent (identified by name in XML) and installs a pointer.

Handling a scheduler RPC reply

A similar approach is used when handling the reply from an scheduling server RPC (CLIENT_STATE::handle_scheduler_reply). The RPC returns a interconnected set of basic objects, represented in a SCHEDULER_REPLY object. For each of these basic objects, we see (e.g. lookup_app()) if it's alread present in the CLIENT_STATE structure. If not, we create and insert a new object, then link it (e.g., link_app()) to establish pointers to associated objects in CLIENT_STATE.