947
edits
m (→Problems We Aimed to Solve with Datazilla: probably a more professional word choice) |
|||
Line 28: | Line 28: | ||
* Establish a full, extensible RESTful interface to the data: Datazilla's data and statistical methods should be accessible by all developers and the tools they may wish to craft to use the data. | * Establish a full, extensible RESTful interface to the data: Datazilla's data and statistical methods should be accessible by all developers and the tools they may wish to craft to use the data. | ||
* Statistics should be self-evident: often, Talos+Graphserver and other statistical systems have been approached as a "black box": A number comes out that is "good" or "bad". However, this effectively leaves an interested developer in the dark as to where this number came from and discourages understanding the system and | * Statistics should be self-evident: often, Talos+Graphserver and other statistical systems have been approached as a "black box": A number comes out that is "good" or "bad". However, this effectively leaves an interested developer in the dark as to where this number came from and discourages understanding the system and exploring data. Datazilla was designed to expose the statistics being used so that there are no mysteries here. | ||
* No requirement to update the database every time a test or machine changes: unlike the maintenance nightmare that is the current [http://hg.mozilla.org/graphs/file/tip/sql/data.sql data.sql] in graphserver, the Datazilla schema should be dynamic in response to uploaded data. | * No requirement to update the database every time a test or machine changes: unlike the maintenance nightmare that is the current [http://hg.mozilla.org/graphs/file/tip/sql/data.sql data.sql] in graphserver, the Datazilla schema should be dynamic in response to uploaded data. |
edits