I'd rather eat my own leg than introduce namespaces into the config. That said I stand by the original idea except that.. I've gone back on the idea of re-naming matchers, it potentially introduces upgrade problems without really offering much reward. But I can be persuaded otherwise.
> Serge appeared favorably disposed towards the term Filter, for reasons > discussed in that e-mail. I didn't find a reply from you to that > particular > message, but from your current example, it appears that we're on the same > wavelength now? Yeah I think so. > The idea that once we have the ability to dynamically configure pipelines, > and store pipeline configurations in the database, that there could be > user-specific configuration information. This would allow, for example, > that just before storing a message for a specific local user, we could run > messages through a pipeline built from configuration information > associated > with that user. This would address personalized mail processing, similar > to, but more dynamic than, the current <mailet match="UserIs=..." ...> > approach. Convince me that there is value in this, my problem with it would be that it _might_ mean that it becomes harder to predict the outcome of processing for an individual mail, in that the whole process is no longer explicit. > > add.. a scriptable matcher and scriptable mailet, using BSF to allow > admins > > to create complex rules directly in conf without compilation > > Uh ... didn't you see: > > > - BSF Matcher/Mailet No I didn't! put it down to seasonal laziness. I was recycling your idea expressed earlier though, and my own recent experience with Rhino. > That was the whole point of that line item. I was thinking, at least for > the first cut, of a BSFMatcher/BSFMailet pair whose parameters contained > URLs to scripts. +1 d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
