Nagios 2.0 Event Broker and DB Support

[Sam Stickland]

Alternatively you could just not return structures at all, and simply have a
large collection of get and set methods. You wouldn't need to worry about
interface versioning, you could properly protect the data in use and modules
would work across versions without code change.

Sam

----- Original Message -----
From: "Ethan Galstad" <nagios at nagios.org>
To: <nagios-devel at lists.sourceforge.net>
Sent: Friday, August 15, 2003 4:34 AM
Subject: Re: [Nagios-devel] Nagios 2.0 Event Broker and DB Support


> On 4 Aug 2003 at 11:37, David Parrish wrote:
>
> > > The service struct is an internal Nagios structure definition which
> > > changes between Nagios versions.  If the user module is compiled for
> > > use with Nagios 2.0 and it's definition of the service struct, it
> > > will have problems if it is not recompiled for future versions of
> > > Nagios.
> > >
> > > Off the top of my head, I could overcome this by requiring that the
> > > user modules indicate (by calling a function) what version of Nagios
> > > they are compiled for.  If they report anything but the current
> > > version (or do not report at all), unload them so they can do no
> > > harm.
> >
> > I like the idea a lot, and I can see heaps of potential for some funky
> > dynamic monitoring stuff..
> >
> > In the .h file which modules will #include, add this macro:
> >
> > #define NAGIOS_API_VERSION(x) int __nagios_api_version = x;
> >
> >
> > Each module must insert (near the top) a nice simple line like:
> > NAGIOS_API_VERSION(3)
> >
> >
> > Then, when you dlopen() the module, use something like:
> >
> > #define REQUIRED_API_VERSION 3
> > if (*((int *)dlsym(dlhandle, "__nagios_api_version")) !=
REQUIRED_API_VERSION)
> > {
> > printf("Wrong module version... not loading\n");
> > return;
> > }
> >
> > to get the version number before you call the init function. If the
version
> > number is not exactly right, don't load the module. I think that will
> > work...
> >
> > It might be nice in principal to allow multiple versions or some kind of
> > backward compatibility, but I doubt it's worth it, for the stability you
> > could potentially lose.
> >
> > Just make sure that you increase the api version in the core code
whenever
> > you change it, and it'll be sweet.
> >
> >
> > Also, on second thought, it might be worthwhile putting in some compiler
> > checking #ifdef blocks, so that an old version of a module won't compile
> > with the new headers..
> >
>
> Thanks David - this is exactly what I was looking for. :-)
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01