RE: [NeoStats-Devel] Core CTCP event handling

Justin Hammond wrote:
> Its working now. Cheers.

Cool.

> Onto the next "challenge" then, how will we support other 
> clients sending the CTCP request and process the replies to 
> all "interested" modules?
> 
> Your welcome to have a look at the code path, I was trying to 
> keep all the perl specific calls (ie perl library calls) 
> contained in perl.c, otherwise your stepping into header 
> hell, with lots of standard c functions redefined by perl! 
> (hence that PERLDEFINES directive in perl.c/h)

My plan is mainly to try and remove as much of the conditional compilation
as possible from the core code so that perl.c is the only portion where we
end up with the conditional compilation. This means that the main code path
has to peform the same regardless of whether perl is enabled or not (e.g. my
change last night made the module type system apply to the core regardless
of perl support).

> Also, if your going to look into this, then I also have a "question".
> 
> Right now, Perl Modules can attach to other module (bots etc, 
> like adding commands to SecureServ) after last nights commits 
> (not fully tested yet though). For SecureServ's perl dat 
> support, I had originally planned to have the perl dat file 
> as just a "module" in NeoStats, but it would be *nice* if we 
> could have perl Modules and perl extensions. Perl Extensions 
> would just be associated directly with that module (via 
> mod->pm for that module) and the module can provide any 
> "additional" perl API's needed to access that modules 
> specific data (eg, for SecureServ, we can say, only kick of a 
> scan of a user if they pass the standard dat file checks, so 
> we don't waste resources on calling perl for a already killed user).
> 
> What I was thinking of doing was (using the event subsystem 
> as a example):
> In the event subsystem, adding any perl events to the 
> module->pm struct (eg,
> mod->pm->ModuleEvent), and have the event subsystem check if 
> module->pm 
> mod->pm->is
> valid for each module, and if so, run though the events for 
> the perl "Extension" (could also be done for straight perl modules).
> 
> Timers, commands (and possible the set interface) would 
> appear to operate ok without any changes. The event subsystem 
> branches off because I had to also be able to specify the 
> name of the perl function to call via execute_perl
> (module_ptr->event_list[evt]->pe->callback) as well as the C 
> API to the callback (perl_event_cb)
> 
> So, if your looking into the code paths, maybe you can think 
> how can we have one module both as a C module as well as a 
> Perl Extension? In turn, I can easily add to the perl code a 
> simple API to export "module data" to perl extensions as well.

I don't really follow what you mean and cannot see anything in a recent
commit that explains what the difference between a perl extension and a perl
module is from a coding point of view or how one is loaded and setup.

If you just want to raise an event from NeoStats to both modules and perl,
then it is a trivial change to the if contructs used to issue the event in
SendModuleEvent. 


> Finally, did you ever get perl compiled on your system. If 
> not, send me your config.log and src/Makefile. Perl supplies 
> the CCFLAGS and LDFLAGS via a built in perl extension, so 
> either my configure check isn't working with your setup, or 
> your perl installation is lying about its installation! (from 
> your previous post, its working for CCFLAGS, but not LDFLAGS)

No I have not had success with compiling Perl on my Debian system or in
running it on Windows. Requested files sent off list.

Mark.