Enrique, Thanks ... there will be a day don't worry for cleaning up all this. The mindset now is to add as many critical features as possible without shifting the architecture to accommodate each feature. Each new feature we add pushes the architecture to it's limits and shows us where things fall short. Things will get a bit messy but we're almost there. Replication and SASL are pretty much the big enterprise features we need.
Once all these critical features are there it's a good time to take a big step back and re-evaluate the archtecture and all it's aspects by taking into account the big picture which involves all the functionality. There are some good reasons for this. (1) The architecture does not change considerably with each feature addition so familarity is not lost among the team members. This stuff is hard to begin with and changes made every month might lead to the reintroduction of learning curves which consumes time. (2) Migrations to newer versions are less painful for embedders and users alike. (3) We save big refactoring steps until more than one person can do them so there is more input into the process. More eyes make for better decisions. When we focus on refactoring and only that for a release we can summarize these architectural changes and track them by version. Otherwise everything is just jumbled up together. (4) Until we take a step back and evaluate the big picture it's hard to know what is a good decision and what pushes us further away from the best decisions for refactoring the server to accommodate all aspects. If we try to refactor while working on a feature we're somewhat biased towards the feature being added. It's best to be minimalistic in terms of the amount of change induced to add a feature then step back to solve the infrastructure problems objectively. BTW you might feel that we need to stop now and refactor. That's something to consider too but then how do we know what messed up perterbations the other critical features will impose on the newly refactored code. Alex On 3/15/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 3/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > On 3/15/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote: > > On 3/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > > Ok so you basically have this LDAPConfiguration bean contained under the > > > ServerStartupConfiguration? Meaning I would get and > set the > > > LDAPConfiguration bean on the ServerStartupConfiguration? > > > > I wouldn't put it under the ServerStartupConfiguration. No point to, > > other than lashing two classes together. > > Then the user has to use another call to the spring factory thingy to get > this bean by name again. Instead of having a centrally rooted configuration > heirarchy. OK, there is an extra call. If we agree on the LdapConfiguration bean, then whether it is under the StartupConfig or not doesn't matter to me. > > Instead, the > > LdapConfiguration is read via Spring in server-main Service and used > > in the ServerContextFactory to start the LDAP protocol providers for > > LDAP and LDAPS. > > How does this effect the daemon bootstrappers? Will the daemon code work > the same? Yeah, I have it working. Works identically. > > The issue will be keeping > > protocol config consistent with the other 4 protocols we have. > > Hmmm I agree with the concept but I don't like this outcome. Perhaps I > just need to see the mechanics of it. > > ServerStartupConfiguration is not just for LDAP but for all the services in > the > server. It's a minor point; they can all go under ServerStartupConfig. > > > Can you elaborate a tiny bit more on the configuration changes in the > doco > > > just so there are no questions? > > > > Elaborate as to what, specifically? > > Just verbally put down what you've changed. A summary of it. What was. > What's different now instead of just a configuration snippet. Others > looking at this doco will not have a clue right? Think with the perspective > of someone new trying to dive in and get involved. Provide enough context > so they understand what you did. > > Makes sense? You're leaving a trail this way so others can follow what's > going on and how we got there. Gotcha. "Elaborate" was just a little broad. Enrique
