Hey all, I'm using James as the front end for an email based app I am building. I have a couple questions about best practices and the design I've come up with.
The first question is in regard to user management. The app I've developed uses the recipient and sender extensively in its logic. So I need them in the app's database. However, at the same time, there are a few addresses which James will manage locally. I see at least 3 ways of accomplishing this. 1. My app can create users in James' database (ether using RemoteManager or direct db inserts) as they get created in the application. 2. My app can implement the LDAP protocol which James could use to check the recipient. The drawback here is that the addresses I want James to manage locally have to be in my apps database. Which sort of clutters up the data a bit. 3. If James can be configured to use wildcards (i.e. accept *[email protected]) then it can handle local addresses, and then hand off unknown addresses to a custom Mailet (or Repository). #3 Seems the ideal solution. But it is contingent on James being able to accept wildcard addresses. As well as being configured to lookup local addresses, and failover to a custom Mailet. The second question I have is in regard to a Custom Mailet vs. a Custom Repository. As I mentioned all mail to a non-local user will be pushed onto my application. At first glance a custom Mailet seemed the best way to accomplish this. But now that I've dug into James a bit deeper, I'm wondering if writing a custom repository class would be a better option. Or would it even really matter? The application I am building will have a lot of traffic. So I'm not concerned about the easiest solution from either a development or configuration perspective. I'm concerned about the most efficient (in both memory and processing for James) solution. Thanks for you thoughts or comments. Mike ********************************** Mike Dougherty 858.232.3635 [email protected] Mogiv, Inc. http://www.mogiv.com ********************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
