Something we could leverage ActiveData for is querying for build URLs and test-log URLs given a specific commit (revision) ID. All the requisite data should be in ActiveData right now; we'd just like a simple API that takes a commit ID and returns the URLs. Note that we'll have to do a bit of processing because the build URLs are in different parts of the Pulse JSON depending on the build type.
Is this meant for human use, or machine use? The former is best built with a bit of JS on a static page, the latter may be best built as a service endpoint. I would like to avoid adding service endpoints for specialized queries; a well crafted query should be good enough for any client to use. Maybe we really want saved, parametrized, queries: The query can be crafted using the Query Tool, and shared with clients. The query can be updated without the clients' knowledge should the location of URLs change in the future. We already can save queries, and queries are already able to accept parameters in a limited sense, so it is not much more work to implement saved parametric queries. Here is an example of what a saved parametric query would look like (maybe we should implement more memorable names too?) > http://activedata.allizom.org/FbO3xthk?revision=87ed8f83 Here is a query for a specific revision, > http://activedata.allizom.org/tools/query.html#query_id=FbO3xthk
Instead of a specific interface, how about a some general parameters? The user must be able to read JSON, or suffer with data in a table format.