Andrew and Stefano, Replies to your various messages below.
ACO wrote: > So lets start a discussion about making mailet portable and serve > multiple mail servers, yet not hamper performance. Fine. :-) > I would like MailetAPI to not be bound to JavaMail as that will > mean I will need to support two parallel APIs since we will > need to abandon JavaMail internally (meaning also for mailets) > for performance reasons and to better pull off IMAP. As an aside, can you elaborate on the problems, and why they cannot be resolved by writing a better implementation? Server side IMAP isn't supported at all by JavaMail, so I'm not sure what problem you're seeing, but I'll guess that it has to do with the store interfaces. I'm not sure that we want to use JavaMail, but it is the only standard that we have at the moment if we want the Mailet API to have access to repositories. Otherwise we need to create our own. Most mailets don't need access to a repository notion, and simply process the message handed to them a la a message bean. We still need repository support for at least a class of mailets, but we could move that API to the MailetContext or make it a discoverable service. > I would like to see the removal of > MailetContext.html#bounce Bounce is now handled within the the pipeline, but I'm not sure that we really don't want mailets to have no access to the capability. There ought to be some way for them to tell the context that the message should be bounced, even though the implementation might go back into the pipeline to a bounce mailet. > 1. Additional processing (other mailets might log things > gather statistics, etc) We need to expose discoverable services to mailets, and they can see which ones are available in their context. > I would like to see the removal of: > http://james.apache.org/mailet/org/apache/mailet/Datasource.html The data source and repository related methods don't exist, and never did They were an experimental thing in a never deployed branch of JAMES. The web site has this experimental stuff, and we need to rebuild it with the real API. In respect to repositories, we need to redesign both mail and user repositories. > I would like to see the bindings of > http://james.apache.org/mailet/org/apache/mailet/Mail.html to > javax.mail.* broken. Again, JavaMail is *the* standard. We can try to convince Sun to improve it, and we have an alternative (MIME4J) that provides streaming over mail. I don't believe that removing JavaMail makes sense, but we can loosen dependency. For most mailets, we just need access to headers and body content, which MIME4J can do quite nicely. For storing things, we certainly don't want the JavaMail stuff. But for editing messages, JavaMail comes in handy. Ristretto looks interesting, too, but you should checkout our MIME4J code. :-) > I'd like to see a way to locate "relay servers" meaning those that it is > okay to relay to regardless of authentication. I disagree. That is something that the relay mailets should handle, and be part of their configuration. > I'd like to see the existence of ConfigurationRepository which allows > mailets to generically store/locate values (statistics, etc) I'd like to see us switch to Jakarta Commons Configuration, and get away from the non-standard, read-only, Avalon stuff. There are several implementations of Commons Configuration that should support writable properties. I disagree with mis-use of RuntimeExceptions, having had to debug too many (over)uses of that approach. Stefano and I agree on this, and I'm glad to see that we can continue in this way. Stefano wrote: > I'm planning to create a report with services used via > avalon lookup by current james mailet to resolve issues > not resolvable via API so we have a scenario to think about. Close. JNDI (the standard) lookup. Avalon APIs are to be removed from JAMES. Glad to see that you also want to make more use of JNDI. More things can be exposed as discoverable services, including the ability to post messages into the system. --- Noel
