BOINC Client Communication Infrastructure, Part III

Parsing Responses

When I mentioned earlier about the BOINC XML parser assuming a line-by-line parse what I meant by that the XML responses are relatively flat and is parsed in one pass. This has some interesting ramifications, for instance the relationship between XML elements is determined by what was parsed before it.

For an example of what I mean I’m going to use the uber GUI RPC which dumps the BOINC Daemons entire state and should be called at the beginning of any session. Most of the mini update RPC’s do not contain any relational information so you have to run a quick query against the results to map a workunit to a project for instance.

Here would be the request:



5
5
15

Here is a simplified version of the response:



5
5
13


Alpha Project



alphaapp
Alpha Application



aapp_5.24_windows_intelx86.exe



alphaapp
524

aapp_5.24_windows_intelx86.exe





Test1
alphaapp
524



Test1_0
Test1


Beta Project



betaapp
Beta Application



bapp_5.24_windows_intelx86.exe



betaapp
524

bapp_5.24_windows_intelx86.exe





Test1
betaapp
524



Test1_0
Test1


So in this example you can see that there is no explicit reference to a project in any of the app, app_version, file_info, workunit, and result elements because it is assumed that they all belong to the same project until the next project element is parsed.

This example illustrates what I mean by a relatively flat XML structure. XPath and XQuery would have a hard time trying to return results that are not in a hierarchical in nature.

—– Rom