[ http://issues.apache.org/jira/browse/JAMES-414?page=comments#action_12368604 ]
Stefano Bagnara commented on JAMES-414: --------------------------------------- Also added default value for enableAliases and enableForwarding in #382481 (see JAMES-426) > Add more flexibility to LocalDelivery > ------------------------------------- > > Key: JAMES-414 > URL: http://issues.apache.org/jira/browse/JAMES-414 > Project: James > Type: Improvement > Components: Matchers/Mailets (bundled) > Versions: 2.3.0a1 > Reporter: Stefano Bagnara > Assignee: Stefano Bagnara > Priority: Minor > Fix For: 2.3.0a1 > > While removing the storeMail method from James (JAMES-392) and moving its > logic in the LocalDelivery we could try to improve the configurability of the > LocalDelivery. > Here is a discussion on the mailinglist: > > 1) Should I move the enableAliases/enableForward directly to the > > LocalDelivery? > Yes. > I'm +1 for anything that allows configurations which were limited to being > set once in James but used many times to being refactored to many to many, > which means moving them nearer the point of use. > Of course it also makes sense sometimes to retain a global default. > And we've always applied the principle of least surprise when considering > config questions, try to think through the questions that will arise when > people upgrade, and take that into account when you make config file format > changes. This usually means make it work by default like it did before unless > the users choose to change it. > > I'm not sure that trying to achieve backward compatibility in the > > config.xml is a good idea (we would need a lot of junk in the code and > > in the config to do that). > I understand that. But work through what would be needed to break this, > documentation etc is part of this consideration. > > Please note that I already changed the place where you have to declare > > mailetpackages/matcherpackages and the place you declare the main > > spool repository. > Yeah I noticed, you will have to be prepared to document this and support it > on the users list when the questions flood in. > > 2) IgnoreCase is instead used more than once and by more clients (Not > > only > > LocalDelivery) and so I was thinking that we should move this > > configuration to the UserRepository interface. Should I do that? > It is a global setting, the rfc (I forget) makes user parts case sensitive, > we offer the choice to ignore this globally, anything else would (IMO) just > be confusing. > What benefit would the chnage bring? > > 3) Should I remove the deprecated method storeMail from MailetContext now? > > We also have a few other deprecated methods > ... > > previous release IMHO we can safely remove all of them: do you agree? > Only if the next release is going to be a Major one (i.e. 3.x not 2.x) > > 4) With this change I could split the LocalDelivery in 2 different new > > mailets (leave LocalDelivery for backward compatibility) and create a > > LocalUsersAliasingForwarding mailet that just apply aliasing and > > forwarding for the mails processed and a LocalDelivery that simply > > deliver the message to a repository named like the destination of the > > message being processed (with no lookup on users). This would allow > > much more flexible Configurations. > +1 This is good, and paves the way for richer v'hosting. > > 5) I can add configurations to the LocalDelivery (or the 2 new > > mailets) in order to be able to use a different UserRepository > > (different from the > > LocalUsers) or a different inboxes repositories by allowing local > > "overriding" configurations: what do you think? > +1 Yes, this also is good, and also supports richer v'hosting support. > (The third thing is to modify pop3 & imap handlers to implement combinations > of IP address reverse dns and username naming convention to fudge that part.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
