Danny, - Matcher Parameters
I think we're back to this discussion: http://www.mail-archive.com/[email protected]/msg02345.html, yes? I had initially favored something like: <mailet match="myMatcher" class="myMailet"> <matcher-config:domain>me.com</matcher-config:domain> <myMatcher:otherparam>somevalue></myMatcher:otherparam> <myMailet:somename>somevalue</myMailet:somename> <mailet-config:othername>othervalue</mailet-config:othername> <impliedMailetParam>some value for the mailet</impliedMailetParam> </mailet> where matcher|mailet-config and the matcher|mailet classname are synonyms in context, and just used for illustration purposes. And the above example just illustrates different allowed forms of syntax; no one would ever actually mix them in such an ugly manner. I had favored that approach for compatibility with the current configuration files, and relative ease of implementation. However, reading the above, it appears that another format, more like your current proposal, was my favorite if we didn't mind breaking with the current format: <mailet class="mailetClass"> <filter class="filterClass1" condition=""/> <filter class="filterClass2"> <param name="condition">condition</param> <param name="foo">fooValue</param> </filter> <filter class="filterClass3" condition="condition"> <param name="foo">fooValue</param> </filter> <param name="somename">somevalue</param> <param name="othername" value="othervalue" /> </mailet> 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? - User-specific Pipeline 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. > 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 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. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
