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 <[email protected]>: > > 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? >
