httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: JSON for mod_status
Date Wed, 30 Nov 2016 20:04:38 GMT
On Wed, Nov 30, 2016 at 1:58 PM, Jim Jagielski <jim@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.)

Mime
View raw message