I am one of the many victims of the proxy settings causing BOINC to crash, and sometimes even WinXP (especially on startup) when uploading the results of a processed workunit. Since BOINC downloaded plenty of workunits to last a couple of days, I tried briefly to figure out how change BOINC's setting for network access (I didn't want to disable my network card) so that I could finish processing the work units until a way was figured out to send them.

In doing this though, I opened a file in the BOINC directory called client_state.xml. I didn't look at the file long enough to see if it had the setting (but I suspect it did). What interested me was that all of my proxy settings, including username AND password were stored in the file as plain text. It is annoying that BOINC doesn't use (or isn't capble of using) the settings already stored in the network settings for use by Internet Explorer, Media player, and other programs. But if it doesn't do that, it should at the very least store the information in the registry and encrypt the password.

On another note, I don't like that you can't change a project's settings locally and that you HAVE to use the website. Granted, once the website is running stably, this will not be as big of an issue, but I really think that the ability to change most settings should be available locally, especially regarding computer usage/scheduling and display. Something like that could easily be done by having a BOINC general settings (ie - project workload distribution, general scheduling options, networking, security, etc) and project specific settings (ie - project specific graphics, cache size [both work units and a processing time estimate option would be nice], possibly even settings regarding infomation displayed on the web page, etc). I don't believe it would be all that difficult to do. My programming experience is EXTREMELY limited, but most of the settings are already built in, so it should be more of a matter of creating some sort of interface, which could easily be modeled using the customization options provided in other programs. I can't think of any really good examples at the moment that demonstrate what I am envisioning, but there are plenty of good examples.

Last, it would be nice of the "setiboinc.ssl.berkeley.edu" url would refer you to "setiboinc.ssl.berkeley.edu/sah" instead of "setiboinc.ssl.berkeley.edu/ap" since that page isn't the most relevant use of the server anymore. If there is some other reason for not doing that, then fine, it just tends to be a nuisance for me ending up on pretty much the wrong page every time (since I use autocomplete and always forget and press enter before taking the time to add the "sah" to the end)

That's all. For now.

>On another note, I don't like that you can't change a project's settings locally and that you HAVE to use the website. Granted, once the website is running stably, this will not be as big of an issue, but I really think that the ability to change most settings should be available locally, especially regarding computer usage/scheduling and display. Something like that could easily be done by having a BOINC general settings (ie - project workload distribution, general scheduling options, networking, security, etc) and project specific settings (ie - project specific graphics, cache size [both work units and a processing time estimate option would be nice], possibly even settings regarding infomation displayed on the web page, etc). I don't believe it would be all that difficult to do. My programming experience is EXTREMELY limited, but most of the settings are already built in, so it should be more of a matter of creating some sort of interface, which could easily be modeled using the customization options provided in other programs. I can't think of any really good examples at the moment that demonstrate what I am envisioning, but there are plenty of good examples.

Just a minor note: You got a couple of items in the wrong columns. The workload distribution is based on a value in specific projects, and is not a general setting. The queue length is a general setting as there is only one work queue in BOINC. There would be a bit of difficulty getting the project specific settings updated, as they would have to have an API in each project in order to do this. Each of the projects may have very different specific settngs.

> Just a minor note: You got a couple of items in the wrong columns. The
> workload distribution is based on a value in specific projects, and is not a
> general setting. The queue length is a general setting as there is only one
> work queue in BOINC. There would be a bit of difficulty getting the project
> specific settings updated, as they would have to have an API in each project
> in order to do this. Each of the projects may have very different specific
> settngs.

I was considering the workload distribution as being a "general" setting in that if you had multiple projects, there would be a part in the settings that listed all of the projects you had "attached" where you could set percentages that determine how much CPU time is spent on each project. Since it would include all attached projects, I consider it to be general.

The Queuing I considered to be project specific with the idea of determining how much work to cache in EACH project, not as a whole. That might be useful if you considered one project to have a higher priority or a project giving longer deadlines in the event of some kind of outage. That is something that could go either place, depending how you looked at it, or even both.

Each project requires at least a small download anyway. So I don't see why a small "patch" or "plugin" couldn't be downloaded along with the project specific processing package that would show up in the settings somehow. General settings (either BOINC specifically) or settings applicable to multiple projects such as CPU workload distribution would have a variable settings page to include additions and deletions of projects, something like a list box or a small table embedded into the settings. Those aren't terribly hard for experienced programmers. And since most of the settings are already used or supported in BOINC and written into the programming, it would be more of a matter of changing the source of the settings and adding a "fairly" simple GUI.

I realize that there are some difficulties with it, but overall I think it would be a lot better and easier to use if more of the programs functions were controlled locally. There are other more important things to accomplish like fixing the Proxy bug that makes BOINC crash when it sends it's results back to SETI and acknoledging some of the security issues (such as the password issue I mentioned) and the ability to shut off automatic updating of the projects, which I would recommend being a local, project specific setting. That would give companies the ability to make their own projects and autoupdate those quickly and automatically, while selectively blocking outside projects that might present a security risk.

I guess what I really want is for it to be fairly custimizable for any projects with most, if not all, custimizations having the ability to be set locally. The main purpose of BOINC vs. SETI Classic is the ability to taylor it to any project, so to me, it only makes sense.

> I was considering the workload distribution as being a "general" setting in
> that if you had multiple projects, there would be a part in the settings that
> listed all of the projects you had "attached" where you could set percentages
> that determine how much CPU time is spent on each project. Since it would
> include all attached projects, I consider it to be general.
Multiple machines belonging to the same user all use the same resource share settings even if those machines are not all attached to the same projects. I have machines that are not capable of running every project so they have not been attached to the project(s) that they cannot run. Now given a global set of numbers, just how are you going to set percentages? The independent resource share as it stands is very useful for homogenous farms, and workable for single machines. OK, allow the setting of the resource share on a local machine and allow that to propogate.
>
> The Queuing I considered to be project specific with the idea of determining
> how much work to cache in EACH project, not as a whole. That might be useful
> if you considered one project to have a higher priority or a project giving
> longer deadlines in the event of some kind of outage. That is something that
> could go either place, depending how you looked at it, or even both.
Are you going to download a WU, and not crunch it? They do have deadlines, and if the deadline is reached, you will not get credit, and someone is going to have to wait extra time for credit for their work. A single queue should ensure that downloaded WUs are crunched eventually. Possibly having a setting that indicates that a project should only be downloaded from if your main project is out of work/unreachable, but keep it in a single queue.
>
> Each project requires at least a small download anyway. So I don't see why a
> small "patch" or "plugin" couldn't be downloaded along with the project
> specific processing package that would show up in the settings somehow.
> General settings (either BOINC specifically) or settings applicable to
> multiple projects such as CPU workload distribution would have a variable
> settings page to include additions and deletions of projects, something like a
> list box or a small table embedded into the settings. Those aren't terribly
> hard for experienced programmers. And since most of the settings are already
> used or supported in BOINC and written into the programming, it would be more
> of a matter of changing the source of the settings and adding a "fairly"
> simple GUI.
I agree that this is possible, but it will involve extra programming on the part of all projects.
>
> I realize that there are some difficulties with it, but overall I think it
> would be a lot better and easier to use if more of the programs functions were
> controlled locally. There are other more important things to accomplish like
> fixing the Proxy bug that makes BOINC crash when it sends it's results back to
> SETI and acknoledging some of the security issues (such as the password issue
> I mentioned) and the ability to shut off automatic updating of the projects,
> which I would recommend being a local, project specific setting. That would
> give companies the ability to make their own projects and autoupdate those
> quickly and automatically, while selectively blocking outside projects that
> might present a security risk.
>
> I guess what I really want is for it to be fairly custimizable for any
> projects with most, if not all, custimizations having the ability to be set
> locally. The main purpose of BOINC vs. SETI Classic is the ability to taylor
> it to any project, so to me, it only makes sense.
>
The more machines that you have, the more that you like setting the options one place and letting the options flow everywhere.