On 5/29/05, 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. And if we are going to make this > change, we should at the same time attack the problem Serge wanted to > address, which supports having nested collections, not just Strings and/or > Recipients.
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). All 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). > 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. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
