Maybe you both can agree in some kind of simple plugin interface on source code level, which makes it easy to complile XMail with or without this or that 3rd party plugin. This would make code maintenance and upgrading for all sides secure and easy. This would mean another boost of flexibility, e.g. for embedding Python, Lua or other things ...
All the best, Harald > -----Urspr=FCngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Beau E. Cox > Gesendet: Donnerstag, 6. Mai 2004 09:35 > An: [EMAIL PROTECTED] > Betreff: [xmail] Re: Embeded perl filters for XMail >=20 >=20 > On Wednesday 05 May 2004 09:22 am, Davide Libenzi wrote: > > On Wed, 5 May 2004 [EMAIL PROTECTED] wrote: > > > Hi - > > > > > > Last year I developed a library of c functions to embed the > > > perl interpreter into c/c++ applications. After several successful > > > deployments, I decided to try to 'embed' perl in the XMail server. > > > > > > It works! I have been running it on my personal XMail server > > > for several days and have yet to encounter problems. > > > > There's a better solution that does not involve tweaking=20 > the XMail source > > code. You have one (or more) pre-loaded Perl interpreters running as > > servers bound on certain TCP ports, and you have a very small binary > > (cperl, written in C using sockets) that talks a trivial=20 > protocol with the > > Perl interpreters. You "external" command call will change from: > > > > "perl /home/davide/myscript.pl" > > > > to: > > > > "cperl -s localhost -p 17171 /home/davide/myscript.pl" > > > > If the script is not already loaded in the interpreter, it=20 > will be at > > client connection time. Do I have to proceed? :-) >=20 > Yes, Davide, I understand that approach. >=20 > But even with that approach, the new process overhead=20 > ('fork') remains, > which my code completely eliminates. I understand you do not > want to put yourself in a position to have XMail issues clouded by > code you have not written and/or are not as familiar with as you > would like. In the early days of mod_perl the Apache core developers > had similar reservations concerning 'foreign' code in Apache. >=20 > I think I offer an extremely high-speed solution to perl filtering > in XMail that could be extremely useful in a high-volume server. I > plan to install my changes at a high-volume client site after the > official 1.19 is released and I have had more test time on my > personal server. I will publish my embedding library, 'bempl' and > my XMail patches (mod_xmail ?) on my site in the next few weeks > with stern warnings that the system is beta/experimental and NOT > condoned or supported by you. I will be here to address any > mod_xmail issues that may arise. >=20 > The changes to XMail source are minimal: >=20 > Errors.h - 6 lines > Errors.cpp - 6 lines > Filter.cpp - 17 lines > MailSvr.cpp - 18 lines >=20 > With 4 new source files: >=20 > BEMPLSvr.cpp - 236 lines > BEMPLSvr.h - 51 lines > BEMPLUtils.cpp - 211 lines > BEMPLUtils.h - 51 lines >=20 > By design, mod_xmail and bempl are robust; every 'stupid' thing > I have tested in perl filter code has failed to bring down the system. > The 'bempl.log' gives (optionally) enough information to repair > perl filter mis-coding. All in all, I am very pleased ;) >=20 > Aloha =3D> Beau; >=20 >=20 > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] >=20 - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
