Yes that's it exactly. I'm unimportant but I think that SNURK would be very happy if the time could be found to build.

I didn't see this earlier.
That would work.

It might also be nice to have something like &changedafter=TIMESTAMP and only receive WUs that had a status change after that date/time.

Hi guys,
after some weeks business travelling, I am back and I would like to bring my small contribution to this hot topic.

• As mentioned by GIBA, the device manager menu is well hidden. IMHO, it should be easier to reach. @JM Boullier, you can only bookmark something, if you know where it is. I found the device manager topic, but I am not sure that the Lambda user (layman) will realise that such a functionality is available.
  
• Even if screen scrapping represents an interesting software development challenge (html parsing and DOM), I miss deeply since many years, the possibility to fetch the current results using XML. It seems to me to be more efficient for both: tool developer and WCG bandwidth as well. I asked already for such a solution since over 5 years, unfortunately without any success. jonnieb-uk's comment shows that I am not alone with this wish.
  
• Whatever happens with the web site design, I think that a couple of data connectors (xml-based API) should be clearly defined and that those remain stable over the time. If necessary, a formal Technical Requirements Specification (TRS) could be elaborated by some "advanced" members and agreed and implemented by WCG.
  
• Pirogue (thank you for the WCGDAWS update ) and SNURK make a very good job. I think that better defined and formalised data connectors would help them a lot making their work more reliable and more efficient.

I have currently three master students working on a project for developing a contribution monitoring tool (in the meaning of WCGDAWS). This tool should be a web tool grabbing the results automatically (twice of three time daily) for a specific member (not for all members), generating reports and making the information available other a web site. Additionally - if the project progress allows it - an automated alarming system over e-mail should inform the user if some performance problems occur for a specific host, e.g.: too many invalid or errored results, no work available, etc.

We did already a try last year but unfortunately the project was not completed as expected.
I hope that the current re-design activities of WCG web site will not impact too negatively the progress of this project.
Cheers,
Yves
---
PS: If some members are interested to contribute by defining expectations for data connectors, I could volunteer for writing down the requirements within the scope of a collaborative work.
--
PPS: If some members are interested by the contribution monitoring tool, please let me know. I hope that we could have a reasonable and operating result until year end.

Hi Tullus,
I thank you for the information.
We will take a look on your project and we will consider if we can integrate part of it in ours.
I will keep you inform.
However, we have only a limited time for elaborating a runnable solution.
Cheers,
Yves

Any progress on the xml task list?

I would like to point out this:
http://boinc.berkeley.edu/trac/wiki/WebRpc#pending
If the "Get result list with pending credit" could be extended to "Get results" and the reply also contains:
Application name/Project Name, Result Name, Device Name, Status, Sent Time, Time Due, Return Time, CPU Time/Elapsed Time, Claimed, Granted BOINC Credit
that would be fantastic (and feel free to pour in any other data you might have about the task, we like data).

The structure might look something like this (note: not completely backward compatible with pending.php, so should add a new call, say "user_results.php"):

<user_results>
  <application>
  <name> mcm1 </name>
  <user_friendly_name> Mapping Cancer Markers 7.26 </user_friendly_name>
  <platform>x86_64-apple-darwin</platform>
  <version_num>726</version_num>
  <app_version_num>726</app_version_num>
  <result>
    <name>MCM1_0000269_9260_1</name>
    <device_name>coffe.local</device_name>
    <sent_time> [...] </sent_time>
    <time_due> [...] </time_due>
    [ <return_time> [...] </return_time> ]
    [ <claimed_credit> N </claimed_credit> ]
    [ <granted_credit> N </granted_credit> ]
    <final_cpu_time>35314.390000</final_cpu_time>
    <final_elapsed_time>36599.654345</final_elapsed_time>
    <state>valid</state>
  </result>
    [...]
  </application>
    [...]
</user_results>

And please do share the addition with the rest of the boinc community.