Re: Announcing branch: cachemgr-refactoring

On Fri, Jul 4, 2008 at 12:08 PM, Adrian Chadd <adrian_at_freebsd.org> wrote:
> 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.

I agree.

> 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.

For the raw data, yes.

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

What I'm thinking of is some way to use an internal object-based
representation of the data.
In top of that there should be adaptors to export it to various
formats. "xmlrpc" is to be read loosely, in fact it should not be an
extensive control mechanism (the "rpc" part), but an xml-encoded
data-export stream. html/http should then just be a special case.
The hard part is getting the internal representation right.

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

> 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.

"new" cachemgr can be used as a template / starting point for the
registration mechanisms and message handling.

>> 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.

Agreed. This is however probably for the 3.3 or 3.4 timeframe, unless
someone else steps in and lends a hand.

-- 
 /kinkie