james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Mailet API: Mail Attributes, Recipient Attributes, Mail.duplicate()
Date Mon, 30 May 2005 06:05:21 GMT
Serge Knystautas wrote:

> Noel J. Bergman <noel@devtech.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message