The last “new” idea I wrote on the proposal is to make all the data and operations available through a REST API.
The basis of this idea is to make available the data for any other service/program (maybe even some Nagios plugin, mobile app, etc) and to document it in order to make it usable.
Also, the inclusion of “custom made” tests and this REST API can make a new way of distribution for the tests (avoiding the need of uploading them to a repo). The workers can communicate via the API to obtain the tests to run, provide information about the version of the interpreter, IP, etc. , and send the results back.
I think there is actually some kind of API as I could see on a first sight at the source, but there isn’t a way to access results in XML or JSON, am I right?
This idea might be implemented after implementing other important aspects (custom tests, for example), or whenever you like.
The main reason of a REST API for a project like RubyBench is, in my opinion, the ability to get the tests and upload results (communication in general) with the workers.
Also, the possibility to add some meta data (like the machine, worker version, interpreter, etc) in order to get more statistics from the test results.
Real world usage? Mainly communication with workers, but if we are going to do an API, implementing methods to obtain the results stored is easy, and can be used for example:
Create some kind of alert service, or anything that extends RubyBench functionality.
Obtaining the data in a text format instead of graphs (also, highcharts can export the data, am I right?).
Maybe there is no potential usage of obtaining results’ methods of the API, but in my opinion if we are going to design a REST API, is better to do it complete (and there isn’t mucho more work), don’t you think so?