Nagios 2.0 Event Broker and DB Support

[Jeremy T. Bouse]

	Almost sounds like trying to do the same thing the Sendmail Milter API
does... In it's declaration it does include the version of the API it
was compiled against as well as the callback function routines...

	For example as I was working at one point to try and write a special
milter for the mail servers at work the struct that defined the milter
as as such:

struct smfiDesc csmilter = 
{
        PACKAGE_NAME,           /* filter name */
        SMFI_VERSION,           /* version code -- do not change */
        /* flags */
        SMFIF_ADDHDRS|SMFIF_CHGHDRS|SMFIF_ADDRCPT|SMFIF_DELRCPT|SMFIF_CHGBODY,
        csfi_connect,           /* connection info filter */
        csfi_helo,              /* SMTP HELO command filter */
        csfi_envfrom,           /* envelope sender filter */
        csfi_envrcpt,           /* envelope recipient filter */
        csfi_header,            /* header filter */
        csfi_eoh,               /* end of header */
        csfi_body,              /* body block filter */
        csfi_eom,               /* end of message  */
        csfi_abort,             /* message aborted */
        csfi_close              /* connection cleanup */
};

	Then in the main() function of the milter it would call
smfi_register(csmilter) to register the milter with Sendmail... If it
failed (ie- returned MI_FAILURE) then it could log this fact and exit...
Once it had registered you just 'return smfi_main();' to end your main()
function... Of course Sendmail Milters are threaded so the smfi_main()
just added your milter into the threads currently running... I don't
know much about the internals of how the milter threads are processed
within Sendmail but have had a good bit of experience writing the
milters themselves...

	For completeness here is the smfiDesc structure definition from
libmilter/mfapi.h:

struct smfiDesc
{
        char            *xxfi_name;     /* filter name */
        int             xxfi_version;   /* version code -- do not change */
        unsigned long   xxfi_flags;     /* flags */

        /* connection info filter */
        sfsistat        (*xxfi_connect) SM__P((SMFICTX *, char *, _SOCK_ADDR *));

        /* SMTP HELO command filter */
        sfsistat        (*xxfi_helo) SM__P((SMFICTX *, char *));

        /* envelope sender filter */
        sfsistat        (*xxfi_envfrom) SM__P((SMFICTX *, char **));

        /* envelope recipient filter */
        sfsistat        (*xxfi_envrcpt) SM__P((SMFICTX *, char **));

        /* header filter */
        sfsistat        (*xxfi_header) SM__P((SMFICTX *, char *, char *));

        /* end of header */
        sfsistat        (*xxfi_eoh) SM__P((SMFICTX *));

        /* body block */
        sfsistat        (*xxfi_body) SM__P((SMFICTX *, unsigned char *, size_t))
;

        /* end of message */
        sfsistat        (*xxfi_eom) SM__P((SMFICTX *));

        /* message aborted */
        sfsistat        (*xxfi_abort) SM__P((SMFICTX *));

        /* connection cleanup */
        sfsistat        (*xxfi_close) SM__P((SMFICTX *));
};

	As you can see the first 3 items are defining the milter name, the
version it's built upon and any flags... The rest is just the callbacks
and they need not all be defined... If you don't implement that callback
you simply set it to null... As long as you never changed the order of
the callbacks in the structure in future versions you should be able to
get it to work, just find the older version wouldn't know the newer
callbacks... 

	It's definately possible but I agree it would need a clearly defined
API for the modules to be written against...

	Regards,
	Jeremy

On Fri, Aug 01, 2003 at 08:49:50AM +0200, Christoph Maser wrote:
> i like the idea. the future-compatibility problem should be solvable by 
> a clean module-api with some checks at module-load-time. how often is 
> the internal data-struture changed anyway ? shouldnt it be quite mature 
> by now?
> 
> chris
> 


-------------------------------------------------------
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