On Fri, Dec 2, 2016 at 3:28 AM, Stefan Eissing <stefan.eiss...@greenbytes.de > wrote:
> > > Am 01.12.2016 um 23:14 schrieb Jim Jagielski <j...@jagunet.com>: > > > > > >> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr <wr...@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 > +1. This is possible today simply by requesting 'all'. But an actual query of modules and property names exposed across the entire bean factory would be very interesting. > b) retrieve and aggregate them > We can on a 1:1 basis today (either an entire module scope, or only named properties across all modules, or all of the above.) It would be nice to enhance this as a many:1 response of several targeted data points desired. 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. > One would also register the Property names exposed by the provider, no? > 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. > The current syntax is; https://localhost/status/?proxy_balancer <https://localhost/status/proxy/balancer>;* https://localhost/status/?proxy_balancer <https://localhost/status/proxy/balancer>;Pool=app1,State=Error etc. I'd have no issue with enhancing this to support your proposed syntax. As the already adopted backend of one or more management agents, I'd like to see us continue to accept the existing syntax. Use whichever is most appropriate. The existing design expects the provider to choose a name once and remain consistent. So even as new property/value pairs can be added, the behavior of existing ones remains consistent. Otherwise the interface would have no value to a management agent / snmp replacement. Bill
