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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil