Well I guess git send-email omitted my commit log in the sent patches. So I'll just cover it real quick here:
Patch 1 of 2 adds a new hook currently named 'config-get-cachekey'. This hook allows plugin authors to mutate or build logic around the key used when referencing Qpsmtpd.pm's $_config_cache package variable. Reasoning is if a plugin binding to the 'config' hook can change the discovery of configuration information a plugin then should also have a reasonable amount of control as to how Qpsmtpd looks for cached configuration values. This should make it easier avoid and or account for any key collisions. (see original message in this thread). Patch 2 of 2 is an example of a plugin implementing the new hook. The operation is just a reversal of the stored key (foobar vs raboof). It includes a plugin_tests test and a modification to the config.sample/plugins file to allow the new test to be included in the test suite. On Wed, 2009-09-09 at 14:43 -0700, Jason Mills wrote: > Okay patches submitted. > For for the time delay but I had a bit of hard drive scare last night > after I finished the code but before I could spin the patch. > > Any input, suggestions and or scorn is welcome :) > > - J > > On Tue, 2009-09-08 at 21:22 -0700, Jason Mills wrote: > > Working on it right now :) > > > > On Tue, 2009-09-08 at 21:17 -0700, Ask Bjørn Hansen wrote: > > > On Sep 8, 2009, at 21:05, Jason Mills wrote: > > > > > > > So to the point of the question: Would anyone mind if I patched the > > > > configuration stuff within Qpsmtpd to allow configuration minded > > > > plugins > > > > to alter/hook/stack into how Qpsmtpd discovers and utilizes cached > > > > configuration values? > > > > > > Show us a patch! Changes to make it easier or more powerful to write > > > plugins are generally welcome. > > > > > > (patches with unit tests are even better...) > > > > > > > > > - ask > > > > > >
