The following has been observed using boinc_cmd v 5.8.15 and 5.8.11 on Linux, and also with boinccmd.exe v 5.8.11 on windows.

The disk usage is for each project is correctly reported with the command

./boinc_cmd --get_disk_usage

but is shown, incorrectly, to be zero for all projects in the listing generated by

./boinc_cmd --get_project_status

or

./boinc_cmd --get_state

It is odd that the info comes in three different places - and is a likely source of errors. If the disk usage is thought not to be needed with some of the calls, it should not be output at all, IMHO.

Perhaps the ideal fix would be to re-design the interface so that the calling process can say which items it wants. So --get_simple_gui_info would instead be --get projects results, and so on. Then the code to produce each block of data would only need to be written once instead of three times.

In the absence of such a re-design to the interface, perhaps the second best idea is to make sure that the list of projects is always generated from the same code, instead of duplicating code (or triplicating it as here). Thus the code to respond to --get_simple_gui_info would call the relevant two output routines.

This would also get rid of the oddity that the results are listed in a different order with --get_results compared to --get_state.

River~~

ps, on Linux you might find the following command useful to demo the bug

for x in state project_status disk_usage; do echo get_$x; ./boinc_cmd --get_$x|grep usage:; echo; done

(all on one line) which on my system produced

get_state
disk usage: 0.000000
disk usage: 0.000000
disk usage: 0.000000

get_project_status
disk usage: 0.000000
disk usage: 0.000000
disk usage: 0.000000

get_disk_usage
disk usage: 15409613.000000
disk usage: 4307312496.000000
disk usage: 0.000000

---

Getting disk usage is a time-intensive task sometimes, so it's only calculated when explicitly asked for. get_simple_gui_info data can be fetched using other RPCs too, but I was told it was added for performance reasons. I don't have any info on the reasoning for the rest of the mess.

Note boinc_cmd is an almost 1:1 interface to the C++ library to do RPCs, except for the recently (and fortunately) modified --create_account and --lookup_account.

The whole RPC API is a big mess. After trying to make something useful with the official rpc library, I decided to make my own GUI RPC implementation. Development progress on it currently at 1% though ;)

Getting disk usage is a time-intensive task sometimes, so it's only calculated when explicitly asked for.

Fair comment. And yet, IMO, in that case the misinformation should not be provided at all, ie if the software is not calculating disk usage there should not be a disk usage line in the output or any command other than get_disk_usage.

The whole RPC API is a big mess.

The mess starts, IMO, with tying the API too closely to what the end program does.

It forgets that third party programs (BoincView, for example) want to access the same information by making calls to the client, either directly (as in BoincView) or via boinc_cmd (as in user-brewed scripts).

I hope that any re-write (official or independent) would start from splitting the individual pieces of info down into smaller chunks that can be asked for separately, plus the facility to ask for more than one chunk in any RPC call - this would mean that GUI apps could brew their own collection of chunks to order, without the re-writing of the client end of the RPC. Thus the API would provide the RPC equivalent of doing

--get foo bar

and the client would assemble foo and bar and send them back in one go.

After trying to make something useful with the official rpc library, I decided to make my own GUI RPC implementation. Development progress on it currently at 1% though ;)

Good luck with that - I haven't had the courage to dig any deeper than boinc_cmd as yet...

R~~

I can't ask for independent pieces of data. What I was going to do is a different API to use from the programs, but I'm still tied to the RPC protocol, which doesn't have a way to ask independent values one by one. Changing this needs changing the core client code, and that breaks backwards compatibility (new managers would have to support old protocol for old clients, new clients would have to support old protocol for old managers).