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
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.
On 3/15/07, Emmanuel Lecharny <email@example.com> wrote:
On 3/15/07, Enrique Rodriguez <
> 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
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 :)