I would like a few choices for BOINC's "self-communication":

• Never self-communicate (This is the only computer; BOINC's RCP does not need to search for other computers EVER);
  
• Only self-communicate during uploads/downloads;
  
• Only self-communicate every x minutes
  
• Allow me to instigate a self-communicate command (check my other machines) now

[edited by debsgr8 for typo]

debsgr8, I get the impression that you don't understand the purpose of BOINC's inter-process communication.

Do you want the short version or the long version?

Okay, then. I'll start off by saying what the BOINC RPC is NOT.

It's not a discovery service. It doesn't search for other BOINC computers on the network.

Now what it IS. The simple version: it is how BOINC Manager controls the core client.

The long version: BOINC has a number of different processes to control and coordinate. It is close enough to describe a "process" as a computer program, such as the core client, boinc.exe. There are a wide range of possible ways that processes can communicate with each other. Examples are named pipes, shared memory, TCP/IP RPC, COM+ RPC, and shared files. The kind BOINC uses is TCP/IP RPC. This means Remote Procedure Call over TCP/IP - the protocol that the Internet is based on.

The reasons for this choice are twofold. Firstly, most of the other choices are platform specific. Shared memory on Unix requires different code to shared memory on Windows. Everything would need writing once for each platform, making lots of extra work for the programmers. The second reason is that TCP/IP allows RPC to work over a network. One process on one computer can communicate with another process on a different computer. The practical result of this is that you can connect BOINC Manager on one computer to control the core client on another computer. This doesn't happen automatically - you need to give the other computer's address, and set up passwords.

In normal use, then, both processes will be on the same computer, and the address that is connected to is the special "loopback" address. This works whether you have an Internet connection or not. The data goes from one process to the networking layer of the operating system, and the operating system sends it straight back to the other process.

1. Preferences, of course. You should be able to set everything which can be set in the config files via GUI dialogue.

2. More sane command line and remote administration. An incompetent newbie like me should at least be able to get it to connect to a project via CLI (maybe it would help to get the user to set a password/key/whatever instead of generating one?)

3. A curses-based interface (at least for monitoring). Check out boinc_curses - it's probably GPL or such. It would be awesome if it or something similar came with the client.

4. More totally secksay graphics. This probably is up to the projects rather than the client (I am not familiar with the system), but if it is up to the client, preferences for eleet machines would be nice; smooth redraw rate, line anti-aliasing, etc. You know, so the screensaver is shiny instead of slightly embarrasing.

5. About the scheduler -- I run it at 100% CPU without any performance problems. Maybe you should think about setting a higher default, at least for multi-core systems. Or maybe other people's experienced vary.

EDIT: Rascally commas.

I have noticed that many members question the way BOINC requests and schedules work. The UD agent just did one work unit after another, but BOINC is much more complex. Using the simple view, this isn't a problem. The complexity is hidden. But advanced users prefer the advanced view, where there is enough information to confuse, but not always enough to inform.

So, I'm pondering ways of visualising the work queue in such a way that users can see at a glance such things as how much work is left before more work will be requested, how long until work will be reported, and how deadlines and scheduling is handled.

That's a lot of information to get out of a simple infographic, so I'm wide open to ideas. My current thinking is some kind of timeline view, showing work in progress, work queued, deadlines and estimated scheduler times.