Re: separating the monitoring engine from the display
Doug Hughes (Doug.Hughes@Eng.Auburn.EDU)
Tue, 23 Jan 1996 08:12:43 -0600
>> 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.
>
>#3 by itself would definately be very nice, but I'd really like to also
>like to use tkined as a front end to a network inventory/configuration
>database (which is really #4). This seems like the best of all worlds.
>The possibilities seem endless. Scripts could be written to tie in
>various network services (e.g., DNS, bootp) to the database. It seems to
>me that this has so many possibilities that I'm curious as to what
>argument there might be for going with just #3 instead? (other than
>perhaps #3 is easier to implement)
>
>Wouldn't mSQL be a fine and dandy engine for this?
>
>---
mSQL is indeed fine. It would be even better, IMHO, if it had support for
indexing on non-key/non-unique fields. It would also be nice if it had
a float type and a multi-field key option. Of course, that's a topic
for another list...
I think if a database option were chosen, the back-end should be as plug
and play as possible with a database module that conforms to a defined
set of criteria. This way you could plug in Sybase, Oracle, Informix, mSQL,
typhoon, qddb, or whatever database you wanted.
I use mSQL and scotty right now to collect frames per second and %colls from
all of our hubs and Lan probes. It provides good statistics, and will make
some fine graphs (once I get around to throwing together some BLT and/or
plplotftk stuff)
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
doug@eng.auburn.edu
Pro is to Con as progress is to congress