Am Sonntag, den 14.05.2006, 17:43 +0200 schrieb Stefano Bagnara:
> Norman Maurer wrote:
> >> I didn't think about this too much but there is at least one thing I 
> >> would not like to include in a final release and is the smtp 
> >> chainhandler stuff. I would like to hide it from the external until we 
> >> don't have a real modular solution. An example is the way I did it for 
> >> POP3 (simply hardcoded the default chain so the config.xml does not 
> >> declare the commands).
> >>
> >> I need to think more about other things I don't like in the current 
> >> trunk to be in a final release, but I would like to hear the roadmap 
> >> from the other committers too.
> >>
> > 
> > If you hardcode the SMTPHandler stuff how to enable / disable some
> > features which are configured in the specific handler command ? Do you
> > want to move the configure to the "main" SMTPHandlerConfiguration ?
> > But i also agree that that the configure of the handlers in config.xml
> > is not the best solution cause so its easy to break stuff at all.
> 
> I just don't like the current cmdhandler to be an "user" feature. So I'd 
> like to hide it to the standard user. If we add a default hardcoded 
> configuration then we can add a webpage/wikipage telling the developers 
> (advanced users) that there is an unsupported way to alter the default 
> cmdhandler behaviour.
> 
> Maybe we should move handler configurations to the main smtphandler 
> configuration for this to happen, but I think it is not good to leave so 
> much power to the standard user.
> Furthermore, as I don't like the way current handlers works, I will try 
> to propose something different (or something built on top of them) for 
> future James releases, and I would not like to be bound to backward 
> compatibility for this issue.
> 
I fully agree. And i whould also prefer to move the configs to the main.

> >> I propose that everyone having issues with the 2.3.0a3 release features 
> >> should add a JIRA issue and that we may vote and comment the issues so 
> >> that we will have a clear roadmap to work in.
> > 
> > That whould be the best solution. The roadmap should be clear before
> > publish the "final" 2.3 release
> 
> Imo, the roadmap should be clear before we merge any other code to the 
> 2.3 branch.
> 
> As I said I'm not a fan of the 2.3 branch on the current feature set, so 
> I want to know from the supporters of this branch what kind of 
> features/fix/changes/tasks they intend to be included in 2.3.0.

I whould like to see the JAMES-489 merge to the 2.3 release.

bye Norman

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply via email to