Alan Hannan <alan@gi.net> said:
Alan> Hmm, this really intrigued me, so I went to look, and it
Alan> sounds like you're talking about 'netguard'. (Is this
Alan> right, gurus?)
I already wrote that we don't work on netguard anymore.
Alan> Thanks alot, and I'll look forward to hearing anything at
Alan> all about the itneraction of a network monitoring server and
Alan> using tkined as a client....
I will try to briefly look at some possible solutions:
1) Do it by hand. This means that you can write your personal monitoring
scripts easily once you know enough about Tcl and the scotty
extension. This solution has a lot of flexibility, although you
have to write the code yourself. Available now. :-)
2) Design a monitoring server like netguard. This solution requires to
define a common way to describe your monitoring jobs, where the
data should go and how the data should be filtered/condensed. Tkined
uses special scripts to interact with the monitoring server.
3) Split Tkined into a client/server application where you can remove the
GUI from the `Tkined engine' itself. This leads to a monitoring
server much like solution 2) but it allows to use the same
monitoring scripts with and without a GUI. If done right, you will
be able to connect to the monitoring server, modify it and
disconnect again. The configuration of the monitoring server is
simply stored in the *.tki map file (which will be real Tcl code
instead of the ugly Tcl-like format used now).
4) Implement a stand-alone monitoring server that uses a database
backend to store the data and also its configuration. There are
some sample scripts of this sort in the bones directory (see bogart
and bogart.conf). This is a variation of 2) and real database guys
will love a solution like this. Tkined would need some scripts to
manipulate the database.
I think approach 3) is the way to go. Using a pseudo X11 server might
be a short term solution. Separating the `Tkined engine' (I have no
better name for it) from the GUI will allow to feed multiple GUIs
efficiently and it keeps Tkined independend from software packages
other than plain Tcl/Tk.
The remote access currently implemented does not do this job right
because it uses scotty processes to handle the communication. A real
solution should use the same communication primitives internally and
with remote GUIs. I hope I will find some time to work on it soon. If
someone wants to help, please let me know.
Juergen