On Fri, Jul 4, 2008 at 11:42 AM, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > On fre, 2008-07-04 at 10:24 +0200, Kinkie wrote: > >> First thing, whatI already mentioned on -dev. >> cachemgr is over HTTP, might as well show that up. This is a very >> simple task but it'll make life MUCH easier for external tools' >> developers. > > Yes, and somewhing we all agreed on I think..
Yes. >> That's another very interesting possibility, but I haven't really >> thought of it. The data cachemgr displays are semi-structured but the >> structures differ quie a lot between one view and the next. If a >> common ground can be found, it'd be interesting to follow it. > > Just forget the existing cachemgr displays if looking for structure. > Instead start from the SNMP data as Adrian said, and I also said earlier > in the cachemgr discussion. Trying to convert the existing cachemgr > displays into something more structured simply isn't worth the effort > when there already is a well structured view of pretty much the same > data in the SNMP interface. 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. > The existing cachemgr interface is really only meant as a debug and > diagnostics tool. Data collection is best done using SNMP. > Enabling an XMLRPC view of the SNMP data is an interesting topic, and > would enable a whole range of new tools access to the Squid performance > counters and status indicators. > > If there is things missing in the SNMP MIB these should be added there, > instead of trying to invent new structures for this data. 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? -- Kinkie
