Am 28.03.2022 um 15:24 schrieb Stefan Eissing:
Am 28.03.2022 um 14:28 schrieb Rainer Jung <rainer.j...@kippdata.de>:
I am thinking about adding a JSON output format to mod_status and mod_info as
an option controlled by a query string parameter.
Since writing simple data structures from these modules is much simpler than
parsing and processing a JSON structure, I would expect it to be based on
simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and
HTML output. IMHO no need for a JSON library just for this use case.
Of course, this will slightly bloat the code with "if" statements and roughly
double the amount of ap_rputs() and ap_rprintf().
For mod_status this probably means introduction of a new AP_STATUS_JSON value,
so that in theory other modules could in the future update their status
extensions with JSON support. In the meantime it might mean, that if a modules
extends mod_status output, the result when asking for JSON output is no valid
JSON (mix between mod_status JSON and mod_something providing HTML or text).
For our own modules, especially mod_proxy, this can of course be fixed (and I
will fix this). For mod_info, we do not have such an extension problem wrt.
3rd-party modules.
Any comments up-front before I try to prototype this?
+1 (a big one)
Suggestion: we could add an additional `status_hook` like `status_json_hook` so
that existing one do not get confused?
Doh, of course, haven't thought about this degree of freedom. Makes
sense. Need to think how to make that new registration future feature
proof, so that we don't need a new hook for every new status feature
which is output incompatible.
Thanks and regards,
Rainer
