Plugins on CPAN
Juerd Waalboer
I would like (no, LOVE) it if I could release my Qpsmtpd plugins to
CPAN. This has so many advantages, it's not even funny :)
- POD documentation with perldoc, and nice HTML documentation on
search.cpan.org.
- Automated upgrades through CPAN and CPANPLUS client software.
- Automatic mirroring to dozens of CPAN mirror sites.
- Use of CPAN Ratings (star system)
- Check for (and with CPAN/CPANPLUS, automatically install) CPAN module
dependencies (like DBI for databases).
- Use of search.cpan.org's diff and grep utilities
- Use of the Perl RT system for bug reporting and tracking.
- It makes it easy for linux/* distributors to release packages for
individual plugins: RPM and DEB packages can be generatde
automatically, others probably too.
And last, but certainly important:
- Increased visibility for Qpsmtpd.
The simplest way to make this work is to just use regular Perl modules,
preferrably in the Qpsmtpd::Plugin::* namespace. For this to be
succesful, several things are needed:
1. The plugin loading code must be changed to allow loading Perl modules
in addition to regular plugin files. I believe the changes would be
minimal.
2. Documentation that sums up the requirements for a Perl module-ized
plugin for Qpsmtpd. Basically, a more verbose version of $eval in
Qpsmtpd::Plugin->compile.
3. A HOWTO that guides plugin writers who would like to release their
plugin on CPAN, including how to request a CPAN account, how to write
POD documentation, etcetera.
If the whole idea is generally considered a good idea, I volunteer to do
these things.
--
Met vriendelijke groet, Kind regards, Korajn salutojn,
Juerd Waalboer: Perl hacker <#####@juerd.nl> <http://juerd.nl/sig>
Convolution: ICT solutions and consultancy <sa...@convolution.nl>
1;
a...@develooper.com
On May 10, 2008, at 2:38 PM, Juerd Waalboer wrote:
> If the whole idea is generally considered a good idea, I volunteer
> to do
> these things.
+1!
--
http://develooper.com/ - http://askask.com/
a...@develooper.com
On May 10, 2008, at 2:38 PM, Juerd Waalboer wrote:
> 1. The plugin loading code must be changed to allow loading Perl
> modules
> in addition to regular plugin files. I believe the changes would be
> minimal.
I thought I did that a while ago - you should be able to put in a
module name in the plugins config and it'll load that module rather
than do the wrapper around a single plugin file.
- ask
Juerd Waalboer
> I thought I did that a while ago - you should be able to put in a
> module name in the plugins config and it'll load that module rather
> than do the wrapper around a single plugin file.
Ah, so you did! I had expected this in Qpstmpd::Plugin, but it's in
Qpsmtpd::_load_plugin.
I'm not sure the way to untaint the data is kosher. Essentially,
unvalidated configuration is eval()ed here.
May I suggest to replace the following:
(Comments mine)
if ($plugin =~ m/::/) {
# "full" package plugin (My::Plugin)
$package = $plugin;
$package =~ s/[^_a-z0-9:]+//gi;
my $eval = qq[require $package;\n]
.qq[sub ${plugin}::plugin_name { '$plugin' }]; # <-- shouldn't the first plugin be package??
$eval =~ m/(.*)/s; # <--
$eval = $1; # <-- forced untaint. red flag!
eval $eval;
die "Failed loading $package - eval $@" if $@;
$self->log(LOGDEBUG, "Loading $package ($plugin_line)") # <-- actually, it's already loaded by now.
unless $plugin_line =~ /logging/;
}
with:
if ($plugin =~ /::/) {
($plugin) = $plugin =~ /^([A-Za-z0-9_:]+)\z/
or die "Invalid plugin name '$plugin'";
$package = $plugin;
($filename = "$plugin.pm") =~ s[::][/]g;
$self->log(LOGDEBUG, "Loading $package ($plugin_line)")
unless $plugin_line =~ /logging/;
eval { require $filename }
or die "Cannot load $filename - eval $@";
no strict 'refs';
*{ $package . "::plugin_name" } = sub { $plugin };
}
No string eval anymore. (Note that I did not yet test this code).
Juerd Waalboer
> > to do these things.
> +1!
I'll start documenting then.
What's the preferred patch protocol? Unified diff to the mailinglist?
Hanno Hecker
Ask Bjørn Hansen <a...@develooper.com> wrote:
>
> On May 10, 2008, at 2:38 PM, Juerd Waalboer wrote:
>
> > 1. The plugin loading code must be changed to allow loading Perl
> > modules
> > in addition to regular plugin files. I believe the changes would be
> > minimal.
>
> I thought I did that a while ago - you should be able to put in a
> module name in the plugins config and it'll load that module rather
> than do the wrapper around a single plugin file.
The main disadvantage of having plugins as regular perl modules is,
that you can not load them twice like "normal" qpsmtpd plugins (by
using
my_plugin some_arg
my_plugin:0 other_arg
...)
Hanno
Pedro Melo
Maybe if you create two instances of the my_plugin with the different
parameters.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: me...@simplicidade.org
Use XMPP!
Hanno Hecker
Pedro Melo <me...@simplicidade.org> wrote:
> On May 12, 2008, at 4:59 PM, Hanno Hecker wrote:
> > The main disadvantage of having plugins as regular perl modules is,
> > that you can not load them twice like "normal" qpsmtpd plugins (by
> > using
> > my_plugin some_arg
> > my_plugin:0 other_arg
> > ...)
>
> Maybe if you create two instances of the my_plugin with the different
> parameters.
the plugin name with N being a postive integer. This N is also used for
the namespace of this plugin, so no clashes appear.
Plugins as perl packages (My::Plugin) must have at least one "::" in
their name (no problem, all plugins will probably have a
Qpsmtpd::Plugin:: and can not be loaded twice. Attempting to load these
twice would either overwrite the first or the second load will fail (I
haven't tried yet). The normal plugin's namespace is set at loading
time, while a packages namespace is set in it's "package My::Plugin;"
line.
Downloading plugins as packages from CPAN and then copy it to another
name and edit it can't be the way to go, IMO...
Hanno
Juerd Waalboer
> Plugins as perl packages (My::Plugin) must have at least one "::" in
> their name (no problem, all plugins will probably have a
> Qpsmtpd::Plugin:: and can not be loaded twice. Attempting to load these
> twice would either overwrite the first or the second load will fail (I
> haven't tried yet). The normal plugin's namespace is set at loading
> time, while a packages namespace is set in it's "package My::Plugin;"
> line.
This would be a simple matter of inheritance. On :N, generate a new
package that inherits from the original. Of course, the plugin must then
not use any variables for sharing data. (Should be documented)
Pedro Melo
I understand hown plugins work, I was not clear on my meaning though.
What I meant to say is that maybe if we switch the plugin system to
use not packages but instances of objects, then each one can have a
different configuration.