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 and have a standard set of 
serializers/parsers for JSON, XML, HTML, etc.

As to passing such data around, I've made very good experiences with wrapping 
response status/headers into their own meta bucket type for HTTP/2. That way 
the raw data gets passed around as buckets/through brigades and the main 
connection can serialize that to HTTP/2 frames.

-Stefan

> Am 30.11.2016 um 21:34 schrieb Jim Jagielski <j...@jagunet.com>:
> 
> 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 into a bean, but mod_bmx_status
> uses a local bean with no provision to print out other
> beans as well.
> 
> How does one "extend" the info printed by mod_bmx_status
> via other beans added and populated by other modules?
> 

Reply via email to