Hi Mike, comments are inside..
2010/4/6 Mike Dougherty <[email protected]>: > 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. What about writing a custom UsersRepository implementation ? So JAMES would lookup users directly "via your app" ? > 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). Possible without problems > > #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. > See comments on 2, 3 ;) > 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? This depends a bit on your need. What kind of stuff you need to forward to your app ? The Mail object, the MimeMessage or just some meta info ? > > 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 > ********************************** > > > Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
