On Wed, Nov 30, 2016 at 1:58 PM, Jim Jagielski <j...@jagunet.com> wrote:
> I'm not pushing back on mod_bmx at all... I just think > that there is a better understanding here about "mod_status > producing JSON" than what the changeover to mod_bmx would > be. > > What I would push back on would be having 2 implementations, > since that's just weird :) But if the BMX data format is > "better" then we should use that. > > As Nick said, what is key is that we should produce this > internal data in a known and easily parseable exchange > format, one that we can then directly send as a response > as well as one which we can, via a provider-like interface, > xlate to HTML and other "common" formats. Right now, I > think "plain", "json" and "html" are the only ones we > should worry about. > So to be clear, it is easy to flip mod_status's core data to any one of dozens of formats without any further debate. It is not so easy to carry along the third party hooked status representations of *their* data, not being able to predict how httpd 2.4.x will keep changing behavior during it's 'maintenance' lifespan, not knowing how they presented <p> lists or tables and how they aught to be mapped to json tokens. Contra-wise, turning everything into json-always with 2.next or 3.0 isn't a solution either, since there's no way for mod_status to predict the best representation of the json output from any hooked third party modules. So the best solution, IMO, is to map as beans all of the data to be represented as raw json (and other raw formats), which can be filtered for the 'interesting' data that downstream monitoring clients want to consume, and leave the existing status hook for third party modules to map their data into presentation html (or xml, if we want to go that way.)
