james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-414) Add more flexibility to LocalDelivery
Date Thu, 02 Mar 2006 21:10:40 GMT
    [ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message