PROJECT APP FILE_INFO APP_VERSION FILE_REF WORKUNIT RESULTThese 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.
PREFSThis 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_STATEThis 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.
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.
A similar approach is used when handling the reply from a 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 already present in the CLIENT_STATE structure. If not, we create and insert a new object, then link it (e.g., link_app()) to existing objects in CLIENT_STATE. "; page_tail(); ?>