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. > 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. b) In 'a', include registration of the variable name and not just the OID as today. 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). Accessing the MIB variables internally isn't that tricky. Regards Henrik
signature.asc
Description: This is a digitally signed message part
