divide client state file

[davea]

Currently there's a single client state file. If one item in it changes (e.g. a task's checkpoint CPU time) the entire file is rewritten - could be several MB.

Might be better to divide the state file into a large part that seldom changes, and a small part that changes often. The small part would have to include:

• active task info (e.g. checkpoint CPU time)
• project debt info
• other stuff??

[MikeMarsUK]

Perhaps it could be split by project (and also by volatile / static as suggested)? (would have the advantage that corruption would only affect one project).

Sounds like a good idea, but one possible issue - Can the user still downgrade back to 5.x from 6.x without losing their current workunits? (for example, if the new version they're running turns out to be unstable).

Perhaps a little app in 6.0 which recreates a 5.x style client_state.xml at intervals? (Whenever boinc starts up and also each hour of running?)

Alternatively, perhaps the code which reads the new format could be backported to 5.x, so the most recent version of 5.x could take either format as input.

[Nicolas]

What about using ​SQLite for the client state? (Please don't throw heavy objects at me).