> 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.
Here is my list of needs for MailetAPI: A] Per Recipient Attributes: I need this for DSN support. In ESMTP DSN in the SMTP session a client is allowed to add a NOTIFY and an ORCPT attributes for each recipient (RCPT TO: <[EMAIL PROTECTED]> NOTIFY=SUCCESS,DELAY ORCPT=rfc822;<[EMAIL PROTECTED]>). B] Recipient collection incapsulation: I think we should deny the direct access to the recipient collection. I probably prefer an addRecipient, removeRecipient, recipientIterator(), addRecipientAttribute, removeRecipientAttribute, recipientAttributeIterator(). For DSN purposes it would be cool to be able to keep track of aliasing: "changeRecipientAddress()"?! C] notifyDeliveryStatus() in MailetContext (to replace bounce() that represent only one specific status): the james2.2.0 "bounceProcessor" handling is not enough for full DSN support. We need to be able to notify also DELAYs and for DELAYs we should send a new copy of the mail to the bounceProcessor at each delay. I think we should add a method in the MailetContext to allow the container to decide wether to send notifications or not , wether to copy the message or not. I think that we should remove the bounceProcessor and the use of Mail.ERROR in the mailets and alternatively add a container configuration to be able to customize the error handling. D] Named destinations / repositories: I think you already discussed this ( I found a wiki page about MailetAPIv3 and repositories: http://wiki.apache.org/james/JamesMailetV3). How old is this page? E] If we add SpoolRepositories to the API then we should consider to introduce a better accept(): I think that JMS consumer way to declare attributes for the messages they are able to consume is a good way. F] Fully remove "MailImpl" from the bundled matcher/mailets by moving needed methods to the Mail interface. G] Remove the "void sendMail(MailAddress sender, Collection recipients, MimeMessage msg, String state)" methods from mailetContext: this is only used by LocalDelivery to handle ERROR notifications and this would be solved by notifyDeliveryStatus(). H] Add the definitions of MailDeliveryStatus/es and PerRecipientDeliveryStatus/es in the API: Mailets should know how to add delivery status informations to the Mail and how the can provide good information to MailetContext.notifyDeliveryStatus(). I] Why do we have "Iterator getSMTPHostAddresses(String domainName);" and "Collection getMailServers(String host);" ? They seems very similar. Do we need both? The first is used in RemoteDelivery while the second is used in AbstractRedirect and SenderInFakeDomain. PS: someone should add this new mailing-list to this page: http://james.apache.org/mail.html Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
