I wasn't aware that the BOINC project team feels it is necessary to define what projects should and should not do. I thought it was an open community. I saw an area where I could create and contribute something to the BOINC community, and learn some things along the way. And in so doing, relieve the pressure on the BOINC project team to provide such functionality. Now that you insist on using the current AM structure to deliver all client control, the project no longer interests me. So the BOINC community goes without the functionality until the BOINC project team delivers it, and the BOINC project team goes on complaining about lack of third party code contribution to their project.
When a user signs up for a protein folding project, and it takes over the BOINC operations of their machine without their knowledge nor consent, that would be a great example of an application that is not well-behaved. When a user signs up for a BOINC host monitoring and control project, and it performs only the operations they have requested, either by rule definition, or explicit click, it is still a well-behaved application. Your current approach to security sounds as though all projects run under the same user authorities. And therefore, a data storage project could have valuable data destroyed, or perhaps worse, STOLEN, by any other installed BOINC project that wishes to do so. It requires all the sophistication of a DOS .bat file to do it. (I guess it's a good thing the data storage functionality is non-functional afterall) So yes, BOINC client architecture is flawed and should be enhanced. It doesn't mean there is any need to target my specific idea, round peg or square, and intentionally take actions to block it's implementation. At this point that's what it feels like is occurring. Forgive me if I am not as forthcoming in the future about my intentions, plans and objectives. I see now why people asking questions on this list sometimes seem to be rather elusive about specific details that would be useful in providing a more relevant response to their question. At this point I feel it may be important to reiterate that my signature line is only an indication that I support rose...@home. I in no way speak for nor represent their project. My comments and tinkerings are my own. Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running rose...@home just might! http://boinc.bakerlab.org/rosetta/ --- On Tue, 2/23/10, Rom Walton <[email protected]> wrote: From: Rom Walton <[email protected]> Subject: RE: [boinc_dev] How to locate boinccmd on client To: [email protected], "Charlie Fenton" <[email protected]> Cc: "BOINC dev" <[email protected]> Date: Tuesday, February 23, 2010, 11:46 AM Conceptually account managers manage a BOINC client’s interactions with projects, that is its purpose. Right now that consists of managing preferences, attaching to projects, detaching from projects, changing resource share, etc. It could do more. Projects are just supposed to be used for processing tasks. From a conceptual model you are trying to put a square peg in a round hole. If projects have access to the GPU RPC password, how does anybody actually know the volunteer has consented to anything? What if user attaches to project A and B, both do protein folding experiments. They both participate in a protein folding competition which would increase their chances of getting more grant money, project A decides the easiest way to get ahead is to abort work from all other projects. Merely attaching to the project isn’t a sign of consent that it is okay to do anything other than processing work. At least if the volunteer has gone though the bother of giving you the GUI RPC password, there is some degree of consent. ----- Rom _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
