Discuss Class Architecture for the Core

[XayOn]

As core I've to manage the plugin system and export a basic API with status and a few more information properties

[arivero]

Given that we expect some contributors coming from BOINC, we need to use a nomenclature near to BOINC database system.

Variants:

• There is a concept, Task, intermediate between Workunit and Result. A Task is ready to be assigned to a volunteer, and it becomes a "result" where this volunteer answer the Task. In BOINC, this is simply a state change in the Result Table, but we have found that such approach is confusing for newcomers, so we are going to try this way.
• The "Canonical Result" needs not be a "result" by itself, but some kind of average. So we introduce the concept of Consolidated Result. Note that then we can be more subtle with the validation process: a Task can be invalid (eg, corrupt files in reception) and never come to be Validated, and the process which is strictly equivalent to Validation becomes the Consolidation. And then a Consolidated Result is the object who is delivered during the Assimilation.

[arivero]

So:

A Researcher gives Jobs
A Job gives Workunits
A Workunit gives Tasks
A Task give a Result (or fails)
Not Enough Results for a Workunit give more Tasks
Enough Results for a Workunit give a Consolidated Result.
A Consolidated Result assimilates itself towards the Job Result, and/or produces a new workunit.

[XayOn]

I'm wondering how can we do the parts where a user communicates with a specific task!
Each task now have a volunteer object associated, wich I assume will be created from the view.
Then the user will reply with the result (so, the plugin for that will have task_result() defined as a function to wait for user input). But I'm still lacking something here... like for example why having tasks created before any action comes to them.