> > > > Maybe the time has come to "do a release" (0.9?) and then open things up > > for major cleanups/changes. >
This might actually be 0.85, but that's irrelevant. > > > > -R > > I'm all in favor. > > I'm doing more work on plugins right now and have a bunch more changes in > the pipes. Most of the changes revolve around several practices which I > think all plugins should adhere to: > One thing that would help is if you could split your changes into multiple pull requests -- if we're going to try using github as our mechanism, every pull request should be for one "feature". There's a lot of your changes pending right now which are no-brainers. Typo fixes or other cleanups -- but to apply those without everything else in your tree requires a cherry-pick, which IIRC will wreak havoc with your tree when you try to rebase. (Or maybe not, and I should just start picking and getting the easy ones out of the way so we can focus on the others.) > > store operational results in notes > > Yes. > use a 'reject' option: instead of rejecting messages that fail a test, > offer an option for what to do. > (ex: require_resolvable_fromhost becomes resolvable_fromhost with a > reject option > this allows information to be collected from a plugin when it would > otherwise be unusable > > I'm 50/50 on this one. On one hand, it provides more configuration options and flexibility. On the other hand, it requires people to set more configuration options and increases the complexity of the configuration and may make the simple cases harder. > log a reasonable amount, especially for LOGINFO. I know, I know, > reasonable is hard to pin down, but a little bit of guidance could go a > long ways here: > > DEBUG -> fire hose, spray away logging anything and everything. > INFO -> normal operational info: goal is a one line summary > per plugin > NOTICE -> unusual results that are not errors > > In general, this seems quite reasonable. > I also think logging anything more severe than a WARN event should have > the option to automatically email a sysadmin. > > I'm not a fan of tying in auto-emailing of severe notifications. (I've got a great story about how I took down a corporate mail system 7 years ago that way...) > I'm working on a "Qpsmtpd Big Picture" document that contains a flowchart > of a sample connection, a catalog of all the plugins, what each plugin > does/sets/changes, and what information is made available to subsequent > plugins via notes. It took me quite a while to wrap my head around this, > and that learning curve presents a significant barrier to entry for > potential qpsmtpd users. > > Speaking of opening things up to major changes and cleanups, I have to say > I'm not terribly fond of the check_ prefix on so many of the plugin names. > I think I get the idea behind it, but many of the plugins do more than > check. Many also reject messages that fail their checks, by default. Why > not just drop the check_ prefix entirely, and have the plugin name be > shorter? > > Same goes for plugins like require_resolvable_fromhost. I think its > better to make the plugin resolvable_fromhost, and then offer config > options that govern whether the plugin merely checks, or rejects based on > the outcome of the test. > > This goes with your configuration options direction above. I can definitely get into a naming bikeshed color discussion with both feet -- but will restrain. The bigger issue for me is backwards compatibility. If we change the name of any core plugins, that's going to break users when they try and upgrade. It's pretty easy to leave placeholder plugin wrappers in place, but users will still break if the functionality changes. If you're interested in driving all these changes, maybe we should consider a new target: qpsmtpd2 or something. (I'm not trying to discourage you -- I'm very happy someone is interested in this -- I just don't want to break the current users.) -R
