> Yes, that is a good option as well. Compared to using cache manager, we > would gain easier message parsing and some efficiency. We would lose: > - remote access ability (UDS are local); > - reusable access controls (there are no Coordinator ACLs for now); > - management transaction logging (no Coordinator actions log for now); > - a better understood firewall-friendly text-based protocol (HTTP+CGI > query strings compared to undocumented UDS Coordinator messages). > > Since performance is not an issue here, it feels like using cache > manager HTTP interface would be an overall better approach, especially > if we want non-programmers to be able to script beautiful yet > secure/traceable interfaces.
I completely second Alex' idea. To bring it one step forward, it would feel good to try and unify the data-collection API between CacheMgr and SNMP, so that the same callbacks are invoked for the various components, and have components return a structured language-neutral description of the data, to be rendered by the management framework into text, html, xml, json or SNMP. -- /kinkie
