Re: JSON for mod_status

pd.apache.org/server-status :) JSON: http://httpd.apache.org/server-status?view=json_status With regards, Daniel. On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: I'm thinking about adding JSON sup

Re: JSON for mod_status

On 01/18/2017 03:48 PM, Daniel Gruno wrote: > On 01/18/2017 03:19 PM, Luca Toscano wrote: >> >> >> 2017-01-18 10:56 GMT+01:00 Daniel Gruno > >: >> >> On 01/17/2017 07:33 PM, Jim Jagielski wrote: >> > It all depends on what Bill decides

Re: JSON for mod_status

ted), so > I would require some sort of docs in addition to the actual > code, of course. > >> On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: >> >> >> >> 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: >>

Re: JSON for mod_status

On 01/18/2017 03:19 PM, Luca Toscano wrote: > > > 2017-01-18 10:56 GMT+01:00 Daniel Gruno >: > > On 01/17/2017 07:33 PM, Jim Jagielski wrote: > > It all depends on what Bill decides regarding mod_bmx and if > > it is something we

Re: JSON for mod_status

2017-01-18 10:56 GMT+01:00 Daniel Gruno : > On 01/17/2017 07:33 PM, Jim Jagielski wrote: > > It all depends on what Bill decides regarding mod_bmx and if > > it is something we intent to backport to 2.4.x > > > > Still not sure on how to *use* BMX, or how other modules > >

Re: JSON for mod_status

g/server-status?view=json_status >> >> With regards, >> Daniel. >> >>> >>>> On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-11-30 18:54 GMT+01:

Re: JSON for mod_status

.@gmail.com> wrote: >>> >>> >>> >>> 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: >>> I'm thinking about adding JSON support to mod_status... >>> the "plain" version output really stinks and lacks parity >>

Re: JSON for mod_status

With regards, Daniel. > >> On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: >> >> >> >> 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: >> I'm thinking about adding JSON support to mod_status... >> the &

Re: JSON for mod_status

, so I would require some sort of docs in addition to the actual code, of course. > On Jan 17, 2017, at 12:35 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > > > 2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > I'm thinking about adding JSON sup

Re: JSON for mod_status

2016-11-30 18:54 GMT+01:00 Jim Jagielski <j...@jagunet.com>: > 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 pa

Re: JSON for mod_status

On Fri, Dec 2, 2016 at 3:28 AM, Stefan Eissing wrote: > > > Am 01.12.2016 um 23:14 schrieb Jim Jagielski : > > > > > >> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr > wrote: > >> > >> > >> Note that mod_bmx_status entries

Re: JSON for mod_status

On Thu, Dec 1, 2016 at 4:14 PM, Jim Jagielski wrote: > > > On Dec 1, 2016, at 2:16 PM, William A Rowe Jr > wrote: > > > > > > Note that mod_bmx_status entries focus on what most management > > frameworks are looking for, so thus far, it doesn't deliver an

Re: JSON for mod_status

> Am 01.12.2016 um 23:14 schrieb Jim Jagielski : > > >> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr wrote: >> >> >> Note that mod_bmx_status entries focus on what most management >> frameworks are looking for, so thus far, it doesn't deliver an entire

Re: JSON for mod_status

> Am 02.12.2016 um 06:06 schrieb PKU.孙斌 : > > As to accept headers, that's a pain in the butt if someone just wants to grab > a copy of the data for debugging a custom parser or something. So much > easier to just wget BLAH than to mess with the accept headers on any utility

RE: JSON for mod_status

> To: dev@httpd.apache.org > Subject: Re: JSON for mod_status > > I think a better approach than "?json=true" would be to to respect the > "Accept" header values of "application/json" and "text/json" if they > have the higher priority. > XML output s

Re: JSON for mod_status

> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr wrote: > > > Note that mod_bmx_status entries focus on what most management > frameworks are looking for, so thus far, it doesn't deliver an entire > dataset per connection or worker thread. It certainly could, of course.

Re: JSON for mod_status

On Thu, Dec 1, 2016 at 12:33 PM, Jim Jagielski wrote: > > > On Dec 1, 2016, at 12:53 PM, William A Rowe Jr > wrote: > > > > Finally the query fn in mod_bmx_status performs the callback indicated > > through its invocation to unspool the data in

Re: JSON for mod_status

> On Dec 1, 2016, at 12:53 PM, William A Rowe Jr wrote: > > > Finally the query fn in mod_bmx_status performs the callback indicated > through its invocation to unspool the data in presentation format, which > lives back in mod_bmx and behaves identically for every bmx

Re: JSON for mod_status

On Thu, Dec 1, 2016 at 8:08 AM, Jim Jagielski wrote: > My question is how do the beans, for example, from mod_bmx_vhost > get displayed via mod_bmx_status? > > I understand that one queries mod_bmx for specific beans, but at > the end of the day people still want/need a

Re: JSON for mod_status

My question is how do the beans, for example, from mod_bmx_vhost get displayed via mod_bmx_status? I understand that one queries mod_bmx for specific beans, but at the end of the day people still want/need a comprehensize mod_status-like display. My expectation would be that mod_bmx_status would

Re: JSON for mod_status

First: +1 to have machine-readable output from mod_status, maybe we'll even add test cases! Second: -1 to have various hooks/sub-modules serialize JSON by themselves (or other formats). Instead, I'd rather have us chose a data/bean/binary json API with which to construct objects to pass around

Re: JSON for mod_status

You are looking at one fold of monitoring data. See, for example, mod_bmx_vhost which further extends many beans by hostname. The response generator and framework lives in mod_bmx itself. On Nov 30, 2016 14:35, "Jim Jagielski" wrote: One thing that I can't understand from an

RE: JSON for mod_status

than to mess with the accept headers on any utility we want to fetch with. Rick Houser Web Administration > -Original Message- > From: Jordan Gigov [mailto:colad...@gmail.com] > Sent: Wednesday, November 30, 2016 13:20 > To: dev@httpd.apache.org > Subject: Re: JSON for mo

Re: JSON for mod_status

One thing that I can't understand from an initial look is how the whole hook thing is. In mod_status, we have a hook that is run in mod_status and other modules use to supplement the mod_status output. With mod_bmx it looks like instead whatever "chunk" of data you want to make available, you put

Re: JSON for mod_status

the mod_status hooks to > the redis and memcache socache providers, people came up to > me and asked when, if ever, we would support JSON in mod_status. > ++1 :) S > > What I was hoping for was an implementation that could easily, > and in some reasonable timeframe, be made avai

Re: JSON for mod_status

, we would support JSON in mod_status. S What I was hoping for was an implementation that could easily, and in some reasonable timeframe, be made available to our 2.4.x community. I don't want something that just ends up in trunk, to sit and languish until the day when we eventually decide

Re: JSON for mod_status

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. > &g

Re: JSON for mod_status

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 d

Re: JSON for mod_status

s of mod_status extensions within the stock > > distro, PLUS any mod_status extension providers in the third > > party world of modules? > > > > U the data providers that hook into mod_status simply > push JSON. Same w/ any other extension providers. That is, > ALL

Re: JSON for mod_status

So the only concern is that you prefer XML over JSON??

Re: JSON for mod_status

a data format in this case? > > I'm asking how one would maintain the xslt for the half dozen > json data providers of mod_status extensions within the stock > distro, PLUS any mod_status extension providers in the third > party world of modules? > U the data providers

Re: JSON for mod_status

On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski wrote: > > > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr > wrote: > > > > > > There's no way to anticipate the "right way" to map json > > tables to presentation-level results. > > ??? > > Certainly that is

Re: JSON for mod_status

On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski wrote: > > > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr > wrote: > > > > > > There's no way to anticipate the "right way" to map json > > tables to presentation-level results. > > ??? > > Certainly that is

Re: JSON for mod_status

On Wed, Nov 30, 2016 at 1:22 PM, Jim Jagielski wrote: > Any online examples of it running? It's been a SUPER long > time since I looked at it. And I can't recall what the bean > framework is or does... As with /server-status - not advised unless you EDONTCARE about host

Re: JSON for mod_status

> On Nov 30, 2016, at 1:56 PM, William A Rowe Jr wrote: > > > There's no way to anticipate the "right way" to map json > tables to presentation-level results. ??? Certainly that is the job of the xlate provider that would be used, wouldn't it. Or are you suggesting that

Re: JSON for mod_status

016 at 11:54 AM, Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> 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 n

Re: JSON for mod_status

jagunet.com> 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...? >

Re: JSON for mod_status

-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 for

Re: JSON for mod_status

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 i

Re: JSON for mod_status

On Wed, Nov 30, 2016 at 11:54 AM, Jim Jagielski <j...@jagunet.com> 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 re

Re: JSON for mod_status

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

Re: JSON for mod_status

+1 > On Nov 30, 2016, at 11:54 AM, Jim Jagielski <j...@jagunet.com> 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 produc

Re: JSON for mod_status

Office: 713-529-0800 x 4046 Cell: 713-560-8655 > On Nov 30, 2016, at 11:54 AM, Jim Jagielski <j...@jagunet.com> wrote: > > I'm thinking about adding JSON support to mod_status... > the "plain" version output really stinks and lacks parity > w/ the info we p

Re: JSON for mod_status

ed XML in a decade, so I'm +/-0 on that one. If someone wants to do it, fine, but .. :p > > On 30 November 2016 at 20:08, Luca Toscano <toscano.l...@gmail.com> wrote: >> >> >> 2016-11-30 19:03 GMT+01:00 Daniel Gruno <humbed...@apache.org>: >>> >&g

Re: JSON for mod_status

30 November 2016 at 20:08, Luca Toscano <toscano.l...@gmail.com> wrote: > > > 2016-11-30 19:03 GMT+01:00 Daniel Gruno <humbed...@apache.org>: >> >> On 11/30/2016 06:54 PM, Jim Jagielski wrote: >> > I'm thinking about adding JSON support to mod_status... >>

Re: JSON for mod_status

2016-11-30 19:03 GMT+01:00 Daniel Gruno <humbed...@apache.org>: > On 11/30/2016 06:54 PM, 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 p

Re: JSON for mod_status

On 11/30/2016 06:54 PM, 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. > >

JSON for mod_status

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...?