Re: [NeoStats-Devel] Core CTCP event handling

On 03 Sep 2005, at 3:26 AM, M wrote:

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

Reason is that I havnt committed any code yet that makes any  
difference between them, but if you follow that code path, you would  
see thats its impossible for a perl "interpreter" to live inside a  
real module (because of the IS_STD_MOD or IS_PERL_MOD macros etc.

My post above was how I was thinking about tackling the problems. My  
question was do you see any problems, or a better way to do this?


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

Well, in the current implementation, only one callback per event per  
module is possible (because we use the arrays of events). To support  
perl extensions, we would also have to iterate through a perl event  
structure to handle any perl callbacks that might be needed for the  
perl extension (otherwise the module coder would have to re-invent a  
mini event subsystem for each module he wants perl support for.


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

I got them thanks. I'll look into it tight later or tomorrow.
I'm also the proud new owner of a iBook, and NeoStats fails to  
compile here. I'll be using this as my main notebook once I get  
everything for work installed and will also allow me to hack on  
NeoStats when traveling. (Windows was tightly controlled by our IT  
Dept., so installing other software was *difficult* to say the least)


> Mark.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> For additional commands, e-mail: [email protected]
>
>