httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: JSON for mod_status
Date Fri, 02 Dec 2016 09:28:58 GMT

> Am 01.12.2016 um 23:14 schrieb Jim Jagielski <jim@jaguNET.com>:
> 
> 
>> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr <wrowe@rowe-clan.net> 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.
> 
> Nor does it expose anything from any other beans created
> by any other module.
> 
> Can it?
> 
> If so, exactly how.
> 
>> 
>> Again, it simply iterates the entire contents of each bean presented
>> to it's own print_bean_fn callback. If you have a look at;
>> https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx.h
>> that should give you a somewhat higher altitude perspective on Aaron's
>> API design.
> 
> So mod_bmx_status has to query mod_bmx for "all beans" ??

It seems to me from the name of the callback that this is for "printing" stuff, either all
or only the name matching (which is probably a URL parameter. Fair enough. 

But as Jim pointed out, it would be more powerful if one could
a) detect which beans are potentially available
b) retrieve and aggregate them

So, we'd have BeanProviders that take over a namespace. They register at server start.

ProviderRegistry["proxy/balancer"] -> registered provider hook by the module
ProviderRegistry["proxy/type/h2"]    -> registered provider hook by mod_proxy_http2
ProviderRegistry["proxy/type/h2c"]   -> registered provider hook by mod_proxy_http2

One can query this registry.

For lookups, there is a BeanContext that caches beans once retrieved. So there is not need
to look them up again in the same request. That is passed to all registered bean provider
queries, so that providers can also query for other beans while assembling their own.

A bean produced this way is then send to the client in the requested format using a standard
set of BeanToJSON, BeanToXML, BeanToHTML serializers. The beans just need to be a slim wrapper
around apr_table_t/apr_array_header_t/const char*/int/apr_size_t/apr_off_t/double.

The registry can be mapped to URL space, so 
 * https://localhost/status/proxy/balancer would list the bean there,
 * https://localhost/status/proxy/type would list all beans registered with that prefix.

-Stefan



Mime
View raw message