Chris, to what API are you referring?
o.a.h.metrics and o.a.h.mapred.JobTrackerInstrumentation (JobTrackerMetricsInst). Ganglia, Chukwa, etc. push metrics through this interface. Adding a new interface isn't a small change. For example, the current patch calls JobTracker::runningJobs rather than JobTracker::getRunningJobs; the former is unsynchronized and accesses shared data structures. There have been similar issues caused by metrics frameworks attempting to pull information out of the JobTracker without an audit of the (regrettable) lock hierarchy. If this receives its data through the metrics API, then neither you nor maintainers need to consider how this servlet affects the shared JT data.
No API reports job history in a universally-readable manner (e.g., REST + XML).
That's fair. Again, I like machine-readable formats and wouldn't object to this even if it were an interim solution, but I want to be clear about how it gets its data and what it supports, since we'll be committing ourselves to maintaining both.
Would JobHistory be a better home for this? Much of the data are not currently available in the web UI, let alone in a reasonable format.