Last daily update:
2025-08-13 14:42:58 UTC
17:01:49 ago
Last incremental update:
2025-08-14 07:15:16 UTC
00:29:31 ago
Server time:
2025-08-14 07:44:47 UTC
Currently online:
0 members
313 guests
This is from http://boinc.berkeley.edu/trac/milestone/6.0
High-level goals
Application graphics are produced by a separate program, rather than a thread in the main program as is currently done. This eliminates the problem of the main program, in some cases, not having access to the display. It also eliminates the case where a graphics problem causes a job to error out. The graphics program and the main program can communicate through shared memory or files if desired.
On Windows, run BOINC and BOINC apps under a separate (unprivileged) account. This will provide the same level of "sandboxing" as currently exists on Mac/Unix.
Run only as a service on Windows. Eliminate single-user and multi-user install modes.
Deployment
This will change the interface between core client and app. New apps will be able to run with old clients, and vice-versa; but they won't do graphics. (We won't try to make a client that does graphics with both old and new apps.)
We'll provide a new graphics API, and a working client for testing, as soon as we can - at least 2 months before the public release of the 6.0 client. This will hopefully give projects enough time to develop new app graphics.
After releasing 6.0, there will be a period during which many BOINC users will still be running pre-6.0 clients. If projects were to switch to 6.0 apps, these users would suddenly stop seeing graphics; this would be bad. So what we'll do is change the scheduler so that it will distinguish between 6.0 and pre-6.0 apps, and will send whichever is appropriate for a given client. Projects can keep their pre-6.0 apps for a few months, then phase them out.
If a host has queued or in-progress work at the point of switching to the 6.0 client, this work will be finished by the old app versions, and no graphics will be available during that period.
This is a mild problem with CPDN. If a user switches to 6.0 halfway through a 6-month CPDN workunit, they'll have to choose between not getting graphics for 3 months, or aborting the workunit. CPDN should publicize this, and recommend that their users switch to 6.0 only when their current workunit is finished.
Application graphics are produced by a separate program, rather than a thread in the main program as is currently done. This eliminates the problem of the main program, in some cases, not having access to the display. It also eliminates the case where a graphics problem causes a job to error out. The graphics program and the main program can communicate through shared memory or files if desired.
On Windows, run BOINC and BOINC apps under a separate (unprivileged) account. This will provide the same level of "sandboxing" as currently exists on Mac/Unix.
Run only as a service on Windows. Eliminate single-user and multi-user install modes.
Deployment
This will change the interface between core client and app. New apps will be able to run with old clients, and vice-versa; but they won't do graphics. (We won't try to make a client that does graphics with both old and new apps.)
We'll provide a new graphics API, and a working client for testing, as soon as we can - at least 2 months before the public release of the 6.0 client. This will hopefully give projects enough time to develop new app graphics.
After releasing 6.0, there will be a period during which many BOINC users will still be running pre-6.0 clients. If projects were to switch to 6.0 apps, these users would suddenly stop seeing graphics; this would be bad. So what we'll do is change the scheduler so that it will distinguish between 6.0 and pre-6.0 apps, and will send whichever is appropriate for a given client. Projects can keep their pre-6.0 apps for a few months, then phase them out.
If a host has queued or in-progress work at the point of switching to the 6.0 client, this work will be finished by the old app versions, and no graphics will be available during that period.
This is a mild problem with CPDN. If a user switches to 6.0 halfway through a 6-month CPDN workunit, they'll have to choose between not getting graphics for 3 months, or aborting the workunit. CPDN should publicize this, and recommend that their users switch to 6.0 only when their current workunit is finished.