Re: Announcing branch: cachemgr-refactoring

2008/7/4 Kinkie <gkinkie_at_gmail.com>:

> I agree. Maybe even more structure and data can be shown than what's
> in SNMP, and that's exactly the kind of things I'd like to think
> about.

Well, you should think about it as layers.

There should be a way to pull data out of Squid and export it
somewhere. That can be one "layer". A hierarchical structured type
(like SNMP) is probably good enough for representing anything we want
to.

There then should be a transport layer for getting it -out- of Squid.
This should be HTTP (avoiding XMLRPC, pretty please!) and SNMP.

Finally, you can do whatever you want for presentation layer.

If the SNMP code was made _Much, Much Easier_ to understand -
including the tree definition/iteration/registration code - then it
would be a lot easier to add new SNMP variables. You could then just
split the SNMP transport from the underlying data gathering method and
actually write a simple HTTP layer for accessing it.

> How would everyone feel about changing the cachemgr (possibly breaking
> backwards compatibility) so that it can render better an high-level
> view of the dataspace, while leaving detailed views (possibly even
> more detailed than now) to snmp, xmlrpc and/or structured (but
> user-unfriendly) html / plaintext displays?

I reckon you could just drop modifying cachemgr as it stands and look
at ways of sorting out a proper way of registering reporting modules
in the above described SNMP-like way, and then sort out a way of
separating out the transport layer. You'd then suddenly get HTTP
access for all of the SNMP exported data. Then all of the existing
cachemgr information could be represented in this fashion and your
HTTP frontends can use that.

Adrian
Received on Fri Jul 04 2008 - 10:36:34 MDT