Hi Noel, Ahhh now I am getting some attention... I mean feedback :-)
> I'm not at all in favor of the particular direction being taken for this > bounce handler, but I still have more reading to do. It seems to me that it > is attempting to build a pipeline within in a mailet, rather than take > advantage of matchers, mailets and the processor pipeline. My current > belief, which still begs more reading, is that there will be good code, but > that the code related to his complex configuration is going to be wasted. OK, So I did point out (and so did Danny) in my previous posts that what I was doing was very similar in concept to the mailet/matcher/processor stuff we already have in James, and begged for feedback. However there are several things I just can 't do with the current Mailet API as it stands today (I know that you guys have been asking for feedback, unfortunately I needed to start coding a Mailet to provide this <g>). I think Danny pointed out several additions to v3 Mailets which would help solve many of the requirements I need for this Mailet. Now I have the option to stop working on my bounce handler and maybe try and help out with Mailet v3 coding, or try and finnish a basic prototype and submit the code so that it could be used as a partial "requirements list". Once coding of v3 Mailets is underway I can start migrating the Mailet code to the new API. I also agree that what I am doing now config wise will be wasted, but thats not a big deal. Its not that much code. Thanks, Sergei -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
