On Wed, Nov 30, 2016 at 12:38 PM, Nick Kew <n...@apache.org> wrote: > On Wed, 2016-11-30 at 12:54 -0500, Jim Jagielski wrote: > > I'm thinking about adding JSON support to mod_status... > > the "plain" version output really stinks and lacks parity > > w/ the info we provide via HTML, and it would be nice > > to produce a really easily parseable format. > > > > Thoughts...? > > Ideally that should be the job of an output filter. > If mod_status were to generate a single standard-ish > format, like JSON or XML, a general-purpose filter > could generate other formats. >
The underlying flaw is our extensible status page output. There's no way to anticipate the "right way" to map json tables to presentation-level results. And modules may express multiple tables. See the ssl session cache for one good example, a simply key-value table of some of the current metrics, and a longer table for data. So there either needs to be an extensible data engine as Aaron created, with each status module choosing how to represent it's component data, or mod_status needs two custom hooks, one chain for presentation data and one chain for json data. Existing mod_status extentions in modules only register the presentation hook, so they would not be invoked on a json query. mod_bmx avoids this quandary by placing a different generator for json queries complete with filtering. Based on the interest expressed on this thread, I'm happy to put mod_bmx up for a vote tomorrow after letting this thread run for a bit.
