Serge Knystautas wrote: > Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > Sounds as if we want a Recipient class for internal use, > > rather than just a String containing the e-mail address.
> I don't remember why we started allowing recipients to be String > instead of MailAddress. MailAddress was designed to be for > recipients, but I guess it was clumsy to use or something. Anyway, > then this would have been perfect to extend MailAddress with one that > has attributes. The idea of per-recipient attributes was never > considered (AFAIK). I look at it as a Recipient HAS a MailAddress rather than IS a MailAddress, but in most cases that might be a bit hair-splitting. > I wanted in terms of nesting Collections was to implement what we > wrote into the API years ago... > http://james.apache.org/mailet/org/apache/mailet/Matcher.html. I > rewrote the LinearProcessor to handle this, but I don't think I > finished testing and it needs to be migrated to the MAIN (trunk, > whatever SVN calls it). Post some code to server-dev if you want other eyes to review. :-) > > What do we propose to do about compatibility with existing matchers > > and mailets? One approach would be to keep the existing methods as > > they are (setter/getter pair for Collection<String>), and > > reimplement the old methods in terms of the new ones. > I can't say I have any constructive idea on here without just tossing > the whole API out and starting over with these issues in mind. I don't believe that we need to toss out the existing API wholesale. And we can support API evolution by realizing that the Processor is a Mailet Container, and when we implement <processor name="..." class="...">, we can implement different containers as necessary to support evolution of the API. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
