Yeah I agree with Emmanuel. Enrique let's leave the configuration as it is for now. You are after all just trying to add the SASL stuff and getting bogged down with configuration.
How about this? We tackle the SASL thingy with as little refactoring as possible so we can see what's going on. If it's just nice to have things can wait until we all get on the same page with a refactoring session on the overall server which I think should be done really soon. Perhaps before OSGi attempts are made. We should all be focusing together on these things. Enrique, another point to working in a branch is to see the critical changes made to add your feature besides not breaking the trunk in the process. If you infuse too many nice to have refactorings you blur the core change anyone has to evaluate in the branch. The refactorings mask the real feature changes. Let's all get on the same refactoring page together and figure out the best scheme later. I'm ready to work with you on the refactorings but at a later date. Alex On 3/15/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
On 3/15/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > > > > Other than that I cannot see many issues. However what's wrong with > keeping > > these configuration properties together with the configuration > objects? > > Keeping the configuration in one place may have advantages for us > later when > > we clean things up and put all these parameters into the DIT under the > > system partition for DIT based configuration. > > Anytime you keep anything together, you are restricting modularity. > Today the assumption is that users of the > ServerContextFactory/ServerStartupConfiguration want to use both the > LDAP and Kerberos protocols. This may be correct for most people, but > it simply doesn't scale, especially when you consider the addition of > richer configuration for LDAP/SASL and the Kerberos, DNS, DHCP, and > NTP protocols. I would add something here : we have at least three layer of configuration here : 1) Ldap specific configuration, which are absolutly mandatory (like the port we are listening to) 2) Admin specific configuration, like TimeLimit, SizeLimit, whatsoever 3) Integration configuration (loaded interceptors and whatever is used to modify the way the server is working) IMO, those three layers should be addressed differently. I like the idea of having the last two layers in the DIT, because then we don't have to manipulate a giant XML file or thousands of small XML files. Otherwise, I personnaly prefer manipulate one big file than many little ones. But this is just me :) What else can we say ? let's add a JIRA or create a Wiki page to address this configuration problem, because we won't be able to fix it in the next two weeks. As we might also integrate OSGi sooner or later, this is something we should think twice before modifying the current configuration. Sorry that we have to live with what we have for a little while... But it also prove that we have reached a critical size : it starts to become complicated to change things :) -- Cordialement, Emmanuel Lécharny www.iktek.com
