RE: [NeoStats-Devel] [Commits] r2699 - in trunk: include src

> From: [email protected] [mailto:[email protected]] 
> Author: Fish
> Modified: trunk/src/ctcp.c
> -	SendModuleEvent( EVENT_CTCPVERSIONRPL, cmdparams, 
> cmdparams->bot->moduleptr );
> +	/* because all modules might be interested */
> +	SendAllModuleEvent( EVENT_CTCPVERSIONRPL, cmdparams);
>  	return NS_SUCCESS;

The CTCP interface was designed to allow modules to send correctly formatted
CTCP requests to clients and receive replies to their requests without
having to code it, not to trigger reply events for all modules within
NeoStats. 

As such, I do not think this change appropriate. With this change, a module
is forced to check whether the CTCP reply was meant for it or will have to
duplicate the CTCP code to ensure it only gets responses it wants so
basically makes the whole point of this API redundant. We could have 10
modules make a request and all 10 modules then have to process 10 replies.
If a reply is likely to be useful to multiple modules, then it ought to be
handled as the version request, i.e. the core makes one request for
whichever modules wish to watch it. Version reply support for all modules is
handled by enabling version scan in the core and should not occur if a
module makes the request. 

Since the version request is currently used by StatServ and SecureServ, it
made sense for the core to make a single request which statserv and
secureserv then receive via an event. There seems no point having support in
SecureServ in case it is switched off in the core. It seems needless
repetition and an additional place we have to maintain in the event of a
problem with it. 

If, and only if, there is a need for multiple modules to wish to share the
CTCP "chatter" then we ought to add more core side options, not start having
modules trigger events that are likely to have an adverse effect on modules
which do not expect interference by other modules. Given we have never
supported any CTCP "chatter" other than VERSION in the past, it is unlikely
we have an immediate need for it which is the reason this was not considered
in the initial API other than for VERSION.

Mark.