Re: Announcing branch: cachemgr-refactoring

On Fri, Jul 4, 2008 at 3:53 PM, Henrik Nordstrom
<henrik_at_henriknordstrom.net> wrote:
> On fre, 2008-07-04 at 12:45 +0200, Kinkie wrote:
>
>> 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.
>
> The SNMP agent mib does a good job at that.
>
>> "new" cachemgr can be used as a template / starting point for the
>> registration mechanisms and message handling.
>
> If it's not built along the SNMP mib requirements it won't take off.

I agree. It has to cover all cases.

>> Agreed. This is however probably for the 3.3 or 3.4 timeframe, unless
>> someone else steps in and lends a hand.
>
> A related idea is to begin by building an SNMP<->XML query gateway.
> Would be beneficial to lots of things, not just Squid..
>
> ANyway. the required steps for the proposed "Extended SNMP agent mib
> view" is
>
> a) Clean up how variables is registered in the agent mib.

This has quite a resemblance with what I'm doing with CacheManager.

> b) In 'a', include registration of the variable name and not just the
> OID as today.

Sure.

> I think a good strategy for this is to get the agent mib registration
> code automated from the mib definition, getting rid of the double
> registration we have today (MIB + code).

And use a preprocessor of some sort?

> Accessing the MIB variables internally isn't that tricky.

I certainly hope so :)
What I'd like to do is something a bit more ambitious than just
finding yet another way to get the raw data out, but something which
sits halfway between current SNMP and current cachemgr; in particular
I'd like to be able to offer structured reports, whose rendering is
left to outside tools, in a similar way to what cachemgr.cgi does now.

-- 
 /kinkie