The configurator idea would also have the benefit that changes could be made to configuration settings whilst project servers are down, with the changes coming into immediate effect when they come back up.

I'm off now... If I get any more interest on this idea I will re-post my thoughts under the Wish List message board and possible raise the idea on message boards in the three projects I take part in.

> These configurators could then be downloaded automatically and updated in a
> similar way as projects are attached/removed, in exactly the same way as the
> crunchers are.
>
> The configurator would then just ping the appropriate project with the changes
> made. Thus copies of configuration changes could be kept locally as well as
> remotely.

Hey Garath,

To have the configuration both locally and remotely is a good idea, especially when a project screws up again and they would have to put a backup back, or when you run into problems and have to reformat locally.

Yet that it is a minor rewrite for BOINC? BOINC plays as the shell, let's say it's the OS that all these projects run on. I would've been wrong to say a complete rewrite of the shell would be necessary, since it would only be needed to rewrite the cruncher programs.

Then again, those on non-ADSL & non-Cable would be downloading big cruncher files everytime a rewrite happened, they'd also be uploading their preferences for hopeful safe keeping as well as using a lot more disk space they can use better for other things. Although on example of CPDN, who cares? The WUWU alone takes 600MB. ;)

----------------------
Jordâ„¢

The configurators wouldn't necessarily have to be as large as the crunchers, I just used that example because you spoke of BOINC as a shell... I was just saying that they could be forked off as sub processes in the same manner as the crunchers.

Using detached modules and a dynamic menu approach as suggested in my previous posts would also have the advantage that there would be no "dead weight" code in the shell as each project's configurator would have the code for the associated project and the configurator would be downloaded with the cruncher on signup. The added code in the BOINC shell would be generic launch code for any configurator and thus would still operate only as a shell.

As for the configuration data sent to the servers, this would be no larger than a small ASCII file. (About 4-8Kb) Who's to say that the configurators can't use some sort of RLE compression before sending it? CPDN seems fond of using ZIP files! It might even be possible to transmit the changes using some form of string of HTML parameters.

The cruncher programs wouldn't need a re-write to implement the configurators (other than to implement the new config options that we are talking about adding. Like the seperate suspension of different projects etc...) as the configuration info that they read from is taken from the server, all the configurators would do is send that info to the same place as the web pages do now, it would just be a hell of a lot more flexible allowing offline modifications to take place. Updates to the server would be done when the user next connected.

RLE - Run Length Encoding.

Still, you'd have to send information back and forth. I don't care much about what my BOINC is doing on my 4480Kbit connection as I pay a monthly price for it. But what about the people on dialup?

BOINC was made for cross-platform, all through the internet communication with homebase. Part of it is so you can't cheat, you can't edit your settings at home so you can upload plenty of results and have them all added to you, even if you didn't crunch them at all.

As far as I see it, even allowing a small intrusion into the way BOINC communicates now would only Joe Cheat to try it again, as well as he could on Seti Classic pre version 3.03.

Yes, I tried it as well, and I tried my fair share of cheating at BOINC in Beta days, just to leave posts about that behind on what could be done.

Just try to remember that BOINC was brough in the world so you wouldn't run most of the program, with all its settings and quirks, on your PC. If you get to run BOINC well, most problems are with the contact to the server of the project you are connected to.

Yet there are still a lot of people who cannot run BOINC well, so let us and the devs try to find the cause of that, before we talk about a rewrite of anything major.
----------------------
Jordâ„¢

As far as security is concerned, the configurators wouldn't be able to anything more than you can do on each project's web pages now. It just seemed a simpler way of doing it all. Being able to change the resource settings etc.. for each project from the BOINC window without having to open endless browser windows for each project you're connected to. It's alright when you've only got one project, but when you're dividing your CPU time equally between two or more, it means one browser window for each project whilst you're trying to copy & paste settings from one web page to another!

If you wanted to use a simple encryption algorythm on the locally stored copy of the settings file just to be sure then that would be part of the configurator's code that would be written by the operators of each project like the crunchers.

Call it a front-end to the website settings pages if you will.

> It's alright when you've only got one project, but when you're
> dividing your CPU time equally between two or more, it means one browser
> window for each project whilst you're trying to copy & paste settings from
> one web page to another!

If you ever read the Preferences pages you'd have noticed it wouldn't matter. For each project's preferences page that you set up that you use in another project as well, the preferences are taken over. Automatically. No copy&pasting needed!

Don't say you never read:
These apply to all BOINC projects in which you participate.
On computers attached to multiple projects, the most recently modified preferences will be used. ??

So all you need to do is find those projects that run alike eachother and put them in the Work/School/Home Preferences you want. Seti, Predictor & Pirates run alike. I want to wager a bet LCH does as well. So store them all under preferences for Home.

Then make a seperate one for CPDN, as it doesn't need WUs every 2 days.

See what I am getting at? ;)

----------------------
Jordâ„¢

Still be nice to launch it all from one place though... More for convenience than anything else. Seems neater to me... Call me daft if you want ;)

Daft person... you are. Just read the rules. ;)
----------------------
Jordâ„¢

Come to think of it, it would take less overall bandwidth to change settings using the configurator, especially if you did it on a regular basis, than pulling web pages and sending back changes, as the information would only need to go one way. As for the configurator, you could either choose to download it, or use the web pages as now. Even if you did use it, you'd only be hit for bandwidth once!

As far as cruncher upgrades go, the configurator would only have to be updated if there were significant changes to the cruncher's/project's preferences.

I'd just like to have an option where I could change configurations without having to open a browser window. Maybe it just seems more complete to me that way... I don't know.

It could be done with a program on the side. I mean one that doesn't run from BOINC itself. Just like the majority of games have a seperate configuration program. :)
----------------------
Jordâ„¢

That's exactly the idea I'm having, except that BOINC has a menu which launches them.

Advantages
==========
+ The BOINC security model can be applied to configurators in the same way it's applied to crunchers and their WU's.
+ As they are downloaded with the project files, they can be trusted.
+ They would only do what the project operators allowed them to do.
+ They can be removed/added as the projects are attached/detached/reset.
+ They would be launched from a dynamically generated submenu (see below for a demonstration of settings menu). 
+ The launch code would be very similar (I imagine) to what BOINC already uses to start the crunchers.
+ The code that returned the settings change (I imagine) would be similar to that already returning results.
+ They would run as forked off processes in exactly the same manner as the crunchers are now.

Settings-+-Attach to project
         |
         +-Project Settings  -+-SETI@Home
         |                    +-Predictor
         |                    +-CPDN
         |                    +-etc...
         |
         +-Proxy Server

Starting to look more appealing... I'm not talking about a whole new BOINC after all...

As far as the re-write is concerned, I would imagine (above) most of the code is already there in some form or another, just needing copy/paste and modifying. It would only take Visual C++ (or whatever) to add a submenu. The dynamic generation of entries would take a bit of coding. Tieing in signed up projects with their configurator execs could be as easy as adding an additional entry to the same settings file (not sure of the name) that points BOINC to the crunchers currently! There would be no individual project code inside the BOINC shell itself!

I use Visual Basic not Visual C++ otherwise I might take a pop at it myself! Of course I'd submit my changes to BOINC admin first... I don't want to rub anybody up the wrong way.

One problem with the concept of storing the parameters on the web sites is evident right now. I have adjusted my parameters on SETI and Predictor to get a more correct "balance" of work. Unfortunately, since neither project's schedulars are responding I am not getting the propagation of the settings.

So, changing the work buffer settings to 0 days only works if the system as a whole is alive.

The concept of storing the parameters on the computer has the advantage of being able to effect a change on the local machines even if the web sites/schedulars are missing in action.

I am sure that when we have BOINC stable, GUIs for all clients and are processing for real we will see these ideas incorporated into the system. For the moment, we have bigger problems to solve.

One last point, I would like to be able to control the settings locally with exceptions. For example, most of my PCs would be set with one change on one machine and propagated locally. Others would not be in the local settings pool and I would be able to configure those separately.

So, with this extension, you would have "pool" of settings that could be effected locally without a project schedular and wouild extend the current "venue" system.

That's exactly what I was touching on when I suggested that you could bind settings on a PC by PC basis under each user ID using information already known to the client. (See the "Computers" entry on your stats page!)

Each of these "Computers" entries could have individual settings associated with it, rather than a list stored under the user ID and applied to ALL machines belonging to that user. Even using the Home/School/Work profiles currently supported, there is only support for three PCs to start with, and then if you want to further subdivide PCs in each of those locations, you're stuffed!!

The configurator idea would get around this by storing each PCs individual settings on that PC. It would also have the advantage that you don't have to wait for AWOL servers to get back up and running.

What exactly would be possible with an individual configurator would be up to that project science team. That's the idea anyways.

There's a full idea outline of my proposal on my personal SETI page here!

You can e-mail me and I will be happy to answer your questions.

As a follow-on to this idea, I've added a BOINC resource setup option (HDD space, processor settings etc.) to this menu as shown below.

Settings-+-Attach to project
         |
         +-Resource Setup
         +-Project Settings -+-SETI@Home
         |                   +-Predictor
         |                   +-CPDN
         |                   +-etc...
         |
         +-Proxy Server

The resource setup option would bring up a window (either directly coded into the client or launched in a similar way to all the other configurators) allowing the user to change the general settings from within the client.

I'll add this to the document on my site here. Email me here if you have any questions.