looking at an odbc interface. I tend to agree with Ethan about coding
support for Postgres, MySQL, etc is cumbersome and repetitve if you have
multiple databases.
Also db tend to force a much stricter schema design and changes in data
structures lead to a complete dump/massage/relaod cycle for upgrades which
is a pain.
With the external data interface in 2.x the goal is to enable multiple
display applications exteremely easily.
-sg
On Wed, 16 Oct 2002, Mark Musone wrote:
> Ideally, if the config stuff is stored in a database, everyone would be
> happy!
>
> 1. external CGI's could pull in data quickly and efficiently.
>
> 2. The ability to expand to multiple "display applications" is
> exteremely easy. I for one am working on a much cleaner
> PHP interface to replace the CGI's
>
> 3. The ability to modify the configuration on the fly is almost
> automatically available. Plus the ability to
> Easly also have third party applications modify the configurations is
> also intrinsic.
>
> -Mark
>
> P.S. oh, one other poptions that I've been toying around with is by
> simply having a shared library that
> Returns configuration information, makes it tremendously more expandable
> while still having the control over
> The configuration files.
>
>
>
> -----Original Message-----
> From: nagios-devel-admin@lists.sourceforge.net
> [mailto:nagios-devel-admin@lists.sourceforge.net] On Behalf Of Subhendu
> Ghosh
> Sent: Wednesday, October 16, 2002 10:07 PM
> To: nagios-devel@lists.sourceforge.net
> Subject: Re: [Nagios-devel] regarding upcoming features
>
>
> On Wed, 16 Oct 2002, Ethan Galstad wrote:
>
> > On 16 Oct 2002 at 10:28, Subhendu Ghosh wrote:
> >
> > >
> > > I was going thru the upcoming features list and had a
> > > couple of questions/comments.
> >
> > I just made a few updated to the page, as it hadn't been changed in a
> > long time...
> >
> > >
> > > CGI:
> > > Even if the move to Fast CGIs is made, having the CGIs read the
> > > object
> > > config files directly would still cause the CGIs to be out of sync
> with
> > > the running monitor if the monitor was not restarted.
> > >
> > > Perhaps a "compiled" config created at the the start by the
> > > monitoring
> > > daemon would prevent the out of sync issue.
> >
> > Rather than creating a different format for a compiled config file,
> > I'll just have the daemon write a single cache file containing all
> > object definitions (in raw template format). The CGIs will then be
> > able to read that instead of the normal config files. A compiled
> > config file would probably be faster than the template-based ones,
> > but using FastCGI should nullify that issue.
>
> cache/compile - I guess we both mean the same thing.
>
> >
> > >
> > > Adaptive monitoring:
> > > Also if adaptive monitoring get used - some way to write out the
> > > running
> > > config would be useful. Otherwise a restart would loose the any
> changes
> > > made. Of course the argument could be made that one must modify the
>
> > > configs as well.
> >
> > Yep, the format of the retention file (and status log, for that
> > matter) will be updated to contain current and normal settings for
> > anything that can be changed on-the-fly.
> >
>
> Well if you allow hosts and services to be added on-the-fly then we
> might
> obviate the need for config files for some situations!
>
> but small steps first
>
>
>
--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: sghosh@sghosh.org