asmpro wrote:Does it exist or is there any plan to create additional interface for adding new graphs, deleting graphs ... (for example: command line, SOAP)?
Read on only if there is no other than Web Interface to cacti. If there is, I thank you in advance for pointing it out for me.
We need to add a great number of graphs to cacti. That's why we started thinking of doing it automatically.
The most attractive way of doing seemed to be writing SOAP Service, running inside cacti, offering some of the cacti functions to the external caller (whether this is Java, Perl, C or any other programming language supporting SOAP Client RPC calls). Since we need these functions accessible to Java programming language, we are planning to write Java SOAP Client.
If all goes well, we plan to release sources of both SOAP Service (written in PHP) and SOAP Client (written in Java) to cacti developer community for future adaptations to the future cacti releases.
We might offer some of our development resources for the necesary updates and for adding additional exposed cacti functions.
What do you think about this idea?
I'd like something like this too, but for different reasons. There is definitely some benefit for plugin authors not needing to delve into the interior of Cacti too much. For example, in the Weathermap editor, there's a giant SQL query that is supposed to pull out the list of Data Sources, so a user can pick them. It mostly works, but not quite. I made it by trail and error with my own cacti database. If there were a SOAP interface to retrieve that list then (a) I wouldn't be screwing around inside the Cacti database (better compartmentalization), (b) it'd be right, and (c) it'd probably
stay right in the next release of Cacti too. I would imagine that other plugins could benefit from a more formal interface too.
The implication though, is that you separate the data-layer and the UI in cacti, so that Cacti itself has this separation, which is no mean feat, especially in a project with a growing todo list.
The kind of thing I'm thinking of is RT, where there's an object hierarchy for the actual data, and then a couple of different UIs (mail, REST, web) on top, all calling the same underlying API.
Or, of course, it's a quick fix, and that's cool too, but then it's just moving the problem.
![:-)](./images/smilies/icon_smile.gif)