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 <enriquer9@gmail.com> wrote:
On 3/15/07, Alex Karasulu <akarasulu@apache.org> wrote:
> On 3/15/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > On 3/15/07, Alex Karasulu <akarasulu@apache.org> 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